|
[Sponsors] |
[snappyHexMesh] SnappyHexMesh Internal Flow Example (Diesel Injector) |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
June 19, 2012, 17:19 |
SnappyHexMesh Internal Flow Example (Diesel Injector)
|
#1 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Hello Foamers!
After working through this meshing process on the internal flow of a diesel injector I felt inclined to share my results as internal flow applications of SHM seem to inspire many questions on the forums. !!Disclaimer, I am no SHM expert, so if anyone wants to elaborate on any of these issues please do!! To begin with 2D slice of the 3D injector file I began with: Injector_2D_Slice.jpg Due to the sharp angles that are present in the geometry as well as circular shapes I needed to use surfaceFeatureExtract twice: Code:
surfaceFeatureExtract -includedAngle 180 -writeObj constant/triSurface/SprayA210675doublesmoothascii.stl outputfile Code:
surfaceFeatureExtract -includedAngle 150 -writeObj constant/triSurface/SprayA210675doublesmoothascii2.stl outputfile2 You can then check to see what surfaces were included in the output files you created. Looking at the file "filename_edgeMesh.obj" and taking a slice of the resulting image: surfaceedges1.jpg You can see that the horizontal lines were were not captured by the surface edge program. Looking at the second _edgeMesh.obj file: surfaceedges2.jpg The horizontal edges have now been captured. Note a few extra things have been captured that overlap with the first surface extraction, but that is fine. Next make sure that your blockmeshdict creates a mesh of sufficient density, ie make sure that the interior of the geometry you want to capture has nodes in it. There are a few things to make sure you edit before running a case like this. First make sure you load your geometry: Code:
geometry { SprayA210675doublesmoothascii.stl { type triSurfaceMesh; name nozzle; } }; Code:
// Explicit feature edge refinement // Specifies a level for any cell intersected by its edges. // This is a featureEdgeMesh, read from constant/triSurface for now. features ( { file "SprayA210675doublesmoothascii.eMesh"; level 0; } { file "SprayA210675doublesmoothascii2.eMesh"; level 0; } ); Specify how much refinement you want to perform (Note SHM takes the name of the stl you provide, in this case nozzle, and adds an underscore. Since I want to refine all surfaces I can use the wildcard * to make sure all surfaces are refined): Code:
refinementSurfaces { "nozzle_*" { // Surface-wise min and max refinement level level (8 9); } } Code:
locationInMesh (0.07 0.0 1.3); Code:
//- Highly experimental and wip: number of feature edge snapping // iterations. Leave out altogether to disable. nFeatureSnapIter 10; Code:
layers { "nozzle_*" { nSurfaceLayers 4; } } Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.0.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object snappyHexMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // // Which of the steps to run castellatedMesh true; snap true; addLayers true; // Geometry. Definition of all surfaces. All surfaces are of class // searchableSurface. // Surfaces are used // - to specify refinement for any mesh cell intersecting it // - to specify refinement for any mesh cell inside/outside/near // - to 'snap' the mesh boundary to the surface geometry { SprayA210675doublesmoothascii.stl { type triSurfaceMesh; name nozzle; } }; // Settings for the castellatedMesh generation. castellatedMeshControls { // Refinement parameters // ~~~~~~~~~~~~~~~~~~~~~ // If local number of cells is >= maxLocalCells on any processor // switches from from refinement followed by balancing // (current method) to (weighted) balancing before refinement. maxLocalCells 100000; // Overall cell limit (approximately). Refinement will stop immediately // upon reaching this number so a refinement level might not complete. // Note that this is the number of cells before removing the part which // is not 'visible' from the keepPoint. The final number of cells might // actually be a lot less. maxGlobalCells 2000000; // The surface refinement loop might spend lots of iterations refining just a // few cells. This setting will cause refinement to stop if <= minimumRefine // are selected for refinement. Note: it will at least do one iteration // (unless the number of cells to refine is 0) minRefinementCells 20; // Allow a certain level of imbalance during refining // (since balancing is quite expensive) // Expressed as fraction of perfect balance (= overall number of cells / // nProcs). 0=balance always. maxLoadUnbalance 0.10; // Number of buffer layers between different levels. // 1 means normal 2:1 refinement restriction, larger means slower // refinement. nCellsBetweenLevels 2; // Explicit feature edge refinement // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies a level for any cell intersected by its edges. // This is a featureEdgeMesh, read from constant/triSurface for now. features ( { file "SprayA210675doublesmoothascii.eMesh"; level 0; } { file "SprayA210675doublesmoothascii2.eMesh"; level 0; } ); // Surface based refinement // ~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies two levels for every surface. The first is the minimum level, // every cell intersecting a surface gets refined up to the minimum level. // The second level is the maximum level. Cells that 'see' multiple // intersections where the intersections make an // angle > resolveFeatureAngle get refined up to the maximum level. refinementSurfaces { "nozzle_*" { // Surface-wise min and max refinement level level (8 9); } } // Resolve sharp angles resolveFeatureAngle 180; // Region-wise refinement // ~~~~~~~~~~~~~~~~~~~~~~ // Specifies refinement level for cells in relation to a surface. One of // three modes // - distance. 'levels' specifies per distance to the surface the // wanted refinement level. The distances need to be specified in // descending order. // - inside. 'levels' is only one entry and only the level is used. All // cells inside the surface get refined up to the level. The surface // needs to be closed for this to be possible. // - outside. Same but cells outside. refinementRegions { } // Mesh selection // ~~~~~~~~~~~~~~ // After refinement patches get added for all refinementSurfaces and // all cells intersecting the surfaces get put into these patches. The // section reachable from the locationInMesh is kept. // NOTE: This point should never be on a face, always inside a cell, even // after refinement. locationInMesh (0.07 0.0 1.3); // Whether any faceZones (as specified in the refinementSurfaces) // are only on the boundary of corresponding cellZones or also allow // free-standing zone faces. Not used if there are no faceZones. allowFreeStandingZoneFaces true; } // Settings for the snapping. snapControls { //- Number of patch smoothing iterations before finding correspondence // to surface nSmoothPatch 10; //- Relative distance for points to be attracted by surface feature point // or edge. True distance is this factor times local // maximum edge length. tolerance 4.0; //- Number of mesh displacement relaxation iterations. nSolveIter 10; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 10; //- Highly experimental and wip: number of feature edge snapping // iterations. Leave out altogether to disable. // Do not use here since mesh resolution too low and baffles present nFeatureSnapIter 10; } // Settings for the layer addition. addLayersControls { // Are the thickness parameters below relative to the undistorted // size of the refined cell outside layer (true) or absolute sizes (false). relativeSizes true; // Per final patch (so not geometry!) the layer information layers { "nozzle_*" { nSurfaceLayers 4; } } // Expansion factor for layer mesh expansionRatio 1.0; //- Wanted thickness of final added cell layer. If multiple layers // is the // thickness of the layer furthest away from the wall. // Relative to undistorted size of cell outside layer. // is the thickness of the layer furthest away from the wall. // See relativeSizes parameter. finalLayerThickness 0.5; //- Minimum thickness of cell layer. If for any reason layer // cannot be above minThickness do not add layer. // Relative to undistorted size of cell outside layer. minThickness 0.1; //- If points get not extruded do nGrow layers of connected faces that are // also not grown. This helps convergence of the layer addition process // close to features. // Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x) nGrow 0; // Advanced settings //- When not to extrude surface. 0 is flat surface, 90 is when two faces // make straight angle. featureAngle 90; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 5; // Number of smoothing iterations of surface normals nSmoothSurfaceNormals 1; // Number of smoothing iterations of interior mesh movement direction nSmoothNormals 3; // Smooth layer thickness over surface patches nSmoothThickness 10; // Stop layer growth on highly warped cells maxFaceThicknessRatio 0.5; // Reduce layer growth where ratio thickness to medial // distance is large maxThicknessToMedialRatio 0.3; // Angle used to pick up medial axis points // Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x. minMedianAxisAngle 90; // Create buffer region for new layer terminations nBufferCellsNoExtrude 0; // Overall max number of layer addition iterations. The mesher will exit // if it reaches this number of iterations; possibly with an illegal // mesh. nLayerIter 50; } // Generic mesh quality settings. At any undoable phase these determine // where to undo. meshQualityControls { //- Maximum non-orthogonality allowed. Set to 180 to disable. maxNonOrtho 65; //- Max skewness allowed. Set to <0 to disable. maxBoundarySkewness 3.5; maxInternalSkewness 2.5; //- Max concaveness allowed. Is angle (in degrees) below which concavity // is allowed. 0 is straight face, <0 would be convex face. // Set to 180 to disable. maxConcave 80; //- Minimum pyramid volume. Is absolute volume of cell pyramid. // Set to a sensible fraction of the smallest cell volume expected. // Set to very negative number (e.g. -1E30) to disable. minVol -1e-30; //- Minimum quality of the tet formed by the face-centre // and variable base point minimum decomposition triangles and // the cell centre. This has to be a positive number for tracking // to work. Set to very negative number (e.g. -1E30) to // disable. // <0 = inside out tet, // 0 = flat tet // 1 = regular tet minTetQuality 1e-30; //- Minimum face area. Set to <0 to disable. minArea -1; //- Minimum face twist. Set to <-1 to disable. dot product of face normal //- and face centre triangles normal minTwist 0.02; //- minimum normalised cell determinant //- 1 = hex, <= 0 = folded or flattened illegal cell minDeterminant 0.001; //- minFaceWeight (0 -> 0.5) minFaceWeight 0.02; //- minVolRatio (0 -> 1) minVolRatio 0.01; //must be >0 for Fluent compatibility minTriangleTwist -1; // Advanced //- Number of error distribution iterations nSmoothScale 4; //- amount to scale back displacement at error points errorReduction 0.75; } // Advanced // Flags for optional output // 0 : only write final meshes // 1 : write intermediate meshes // 2 : write volScalarField with cellLevel for postprocessing // 4 : write current intersections as .obj files debug 0; // Merge tolerance. Is fraction of overall bounding box of initial mesh. // Note: the write tolerance needs to be higher than this. mergeTolerance 1e-6; // ************************************************************************* // mesh1.pngmesh2.jpg It's not totally complete as I need to reduce the number of cells (currently 2.25 million), but this shows the overall process and what things to consider. Some thoughts to consider if you may still be having problems: 1) Look at the bounding box you are using with your desired geometry. Could you make it smaller in order to reduce the initial mesh size? 2) Are you going to exceed the maxGlobalCells value? SHM will not abort if you exceed this value, but rather just stop creating new cells. By increasing the initial mesh density defined in the blockmeshdict you increase the chances of this value being exceeded. 3) If you increased the initial mesh density, how many refinement levels are you performing? By increasing the initial density of the mesh, the refinement levels do not need to be as large. Refinement levels dictate how many times each cell is split into smaller cells. So if you increase the density of the initial mesh and keep the refinement level at say 10 or 11, then you may be increasing the resulting mesh calculation much more than you may think. 4) All of these things could contribute to SHM eating up all of your memory and aborting the operation. If you are getting the memory error then try reducing the number of refinement levels, the initial mesh density, and even possibly the number of edge layers being created. Get it to a point where it will successfully run and then if necessary increase these values to get the desired mesh resolution. 5) If you are unsure if your memory is being completely utilized watch your SHM operation using the 'top' command. In my experience SHM aborted right when my memory maxed out. |
|
June 20, 2012, 04:24 |
very nice
|
#2 |
Senior Member
Roman Thiele
Join Date: Aug 2009
Location: Eindhoven, NL
Posts: 374
Rep Power: 21 |
Hej,
thanks for sharing this. I like the idea of the double feature edge extraction and your thoughts on the the snapping edge feature. I have one more question, which of the .obj files do you usually inspect in order to see if you featureSurface extraction was good or not?
__________________
~roman |
|
June 20, 2012, 10:17 |
.obj viewing
|
#3 | |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Quote:
Roman, I'm glad you find it useful, I had a hard time finding internal flows to base my mesh on so figured I would help provide one. The .obj file from surfacefeatureextract that I have been using is the "filename_edgeMesh.obj", which paraview can open directly. Though I'm sure there are other options available, like just looking at the .eMesh file. I believe I have seen some discussion in the forums about trying to open an .eMesh in paraview, but I didn't investigate it much. |
||
June 20, 2012, 17:44 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,982
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
FYI: you can convert "eMesh" files to "obj" and vice-versa: Code:
surfaceFeatureConvert relative/path/file.eMesh file.obj Bruno
__________________
|
|
August 23, 2012, 02:19 |
|
#5 |
New Member
Deepak Cheekati
Join Date: Jul 2012
Location: Chennai, India
Posts: 21
Rep Power: 14 |
HI Everyone
I want to improve the cell density in certain regions of my mesh(created using SHM). It would be great if anyone could help me understand how refinement levels work. Thank You Turbulence. |
|
August 23, 2012, 14:53 |
|
#6 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,982
Blog Entries: 45
Rep Power: 128 |
Hi Turbulence,
You should find answers here: http://openfoamwiki.net/index.php/Sn...als_and_Guides - read the tutorial "A Comprehensive Tour of snappyHexMesh". Best regards, Bruno
__________________
|
|
June 12, 2013, 15:10 |
|
#7 |
New Member
|
Irish 09-
Nice work and thank you! may i ask how you built your blockMeshDict file? how specific did you need to be with your original geometry for this to work? |
|
June 12, 2013, 15:32 |
|
#8 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Hello Dmoore,
I'm glad you found this helpful. The blockMeshDict is just made to be slightly larger than the STL geometry I wish to mesh. Deciding how large the cells of your blockMesh is a bit difficult to determine. You first need to make sure that there are enough cells that some nodes are interior to the STL geometry and some are exterior. Once you accomplish that, you technically don't need to have more cells present. However, the more course your blockmesh starts, the more refinement will be necessary to get your desired mesh from SHM and therefore the longer SHM takes to complete. To even further complicate it though, is that if you make your original blockmesh too refined, then you can potentially have too many cells and I have in the past run out of memory on my desktop with 8GB of RAM, in which case SHM will crash. The problem that is occurring is that the first thing SHM does is refine the original blockmesh and then cuts out the parts that do not touch the STL geometry. Therefore you could be spending a lot of memory refining parts of the blockmesh that will just be cut off later anyway. So you need to balance how much to refine the original blockmesh and then add layers and refinementregions so that you do not just blindly refine the entire blockmesh domain before it conforms to the correct geometry. -Irish09 |
|
June 12, 2013, 15:46 |
|
#9 |
New Member
|
ok. That makes sense. I think my blockMesh is sufficient and I have the privelege of 64GB of RAM, so SHM doesn't limit me too much. I can successfully run the mesh in parallel but then when it comes time to run simpleFoam, I recieve this error:
[1] --> FOAM FATAL IO ERROR: [1] Cannot find patchField entry for contraction_contraction [1] [1] file: /home/teamsoh/OpenFOAM/teamsoh-2.2.0/run/sohWind/bigBlock/processor1/0/p.boundaryField from line 26 to line 45. [1] [1] From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::readField(const DimensionedField<Type, GeoMesh>&, const dictionary&) [1] in file /home/opencfd/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 154. [1] FOAM parallel run exiting I can send you the casefile if you'd like? I noticed that the contraction_contraction line only shows up in the processor dict's.. any thoughts? Does this mean I have incorrectly set up my inlet/outlet/wall conditions? thanks! Dmoore |
|
June 12, 2013, 16:24 |
|
#10 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Dmoore,
It certainly looks like something is wrong with the boundary conditions. I could take a look at the case file if you would like. |
|
June 12, 2013, 17:20 |
Contraction casefile
|
#11 |
New Member
|
I would be extremely grateful to have another set of eyes on it. I am attempting SHM for the first time this these past two weeks. In the past I have used PointWise to mesh. Thank you so much!
|
|
June 12, 2013, 23:21 |
|
#12 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Hello Dmoore,
I've taken a look at your case file and I can see a potential problem, but you will have to let me know as it depends on what you are attempting to model. I am assuming, that you are wanting to model the flow in the interior of this contraction and don't care about the flow on the outside of the device. If I am assuming incorrectly let me know and I can re-evaluate. Based on this assumption of internal flow only, then the current problem I can see has to do with the STL file itself. Since your STL file is not closed, SHM cannot distinguish between the interior and the exterior of the geometry as it can travel from any point A to any point B without traveling through a wall (or inlet/outlet). There are two ways to go about fixing this. The first is to just add a surface where the inlet and outlet are going to be defined in whatever CAD program and then it use that as the STL file. SHM will treat these surfaces as part of the geometry, but does not mean they have to be walls. The second option requires making the original blockmesh smaller than the geometry you wish to mesh, which will essentially clip the geometry at whatever point the blockmesh crosses it and treat that as a wall. I recommend the first option, as the second is a bit more hacking and you don't have as much direct control over the geometry and resulting patches. Irish09 |
|
June 13, 2013, 09:20 |
CAD file vs OpenFOAM
|
#13 |
New Member
|
Yes, you are correct. I should have been more clear. I am trying to simulate an internal flow within the geometry of the .stl file. I took your advice and closed off the two ends of the channel. I also reduced the volume of my blockMesh to fit within the channel so that it can snap to the inside walls of the channel.
surfaceFeatureExtract // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Reading surfaceFeatureExtractDict Surface : "contraction.3.stl" Feature line extraction is only valid on closed manifold surfaces. word::stripInvalid() called for word ��? For debug level (= 2) > 1 this is considered fatal Aborted (core dumped) Unfortunately when I close the ends however, it claims to be an 'open' manifold surface and crashes. The CAD program I have been using, SolidWorks, says otherwise and that it is closed and fully defined. Maybe this is a CAD issue instead of OpenFOAM? Dmoore |
|
June 13, 2013, 09:56 |
|
#14 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 15 |
Hello Dmoore,
I fear I might have slightly led you astray . You have taken ideas from both suggestion 1 and 2, but as I stated before I don't think the second idea was a worthwhile one. From your post I am given the impression that the blockmesh, in its entirety, fits within the contraction. This will not work as it must have nodes on both sides of the geometry in order to find the surface to snap to it. What I was mentioning before could potentially be used so that 2 of the 6 sides of the geometry were not within the original blockmesh, thus creating a boundary that way. I don't recommend this approach though. So I would revert back to the blockmesh file you had previously, in the case file you posted, and keep the geometry closed as you did here. However, the error you are getting has nothing to do with your blockmesh file. As this error is occuring in the surfacefeatureextract function, the blockmesh is not being utilized yet. I went and looked at: OpenFOAM/OpenFOAM-2.2.0/applications/utilities/surface/surfaceFeatureExtract And found that it always prints out "Feature line extraction is only valid on closed manifold surfaces.", so that actually isn't the error, just a statement to remind you. I would think it is a problem with your STL file from your solidworks program. I am unsure if surfacefeatureextract can handle both binary and ASCII STL files, so I would make sure it is ASCII, since I know that works. Otherwise I am unsure of how to help. As the first geometry you provided works fine with the function I would suggest seeing how the two differ. -Irish09 |
|
June 13, 2013, 10:40 |
|
#15 |
New Member
|
Irish 09-
thank you tremendously for your help. I did overlook writing to an ASCII format for the stl file, I think I was rushing . Fixing that allowed me to extract surface geometry and run SHM but with the same original issue of nothing to snap to. It ran for about 20 minutes on 24 cores and returned an untouched blockMesh! haha bummer! I reverted the blockMesh as you sugguested, but for some reason something is still pretty funky . Thanks for the help though! I will post as soon as I am able to find my error! Dmoore |
|
June 15, 2013, 06:44 |
|
#16 | |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,982
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
@Dmoore: Quote:
Because if you didn't use this option, then check the time folders "1", "2" and/or "3", where the intermediate and final mesh will be located. Best regards, Bruno
__________________
|
||
June 17, 2013, 08:47 |
|
#17 |
New Member
|
Wyldckat-
I ran the command line: mpirun -np 24 snappyHexMesh -overwrite -parallel Is there something missing from that sequence? I trying to run the following commands: blockMesh surfaceFeatureExtract (I am working with OpenFOAM v 2.2.0) decomposePar mpirun -np 24 snappyHexMesh -overwrite -parallel mpirun -np 24 simpleFoam -parallel > log thanks! Danny |
|
June 17, 2013, 18:30 |
|
#18 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,982
Blog Entries: 45
Rep Power: 128 |
Hi Danny,
From the list of commands you've shown, the only problem I can see is that running simpleFoam right after snappyHexMesh might not work as expected. I haven't tested the following cases on OpenFOAM 2.2, but the steps I usually follow are demonstrated on the example cases given here: http://code.google.com/p/bluecfd-sin...untimes202_211 Without looking at the "snappyHexMeshDict", it's hard to estimate what might be wrong, but the following come to mind:
Bruno
__________________
|
|
June 18, 2013, 17:10 |
|
#19 |
New Member
|
Dear Bruno-
Thank you for the response (my apologies for the delay of mine!) I have already done the checks you suggested, as well as updated my snappyHexMeshDict to conform to O.F v2.2.0. I think I may revert back to OpenFOAM v 2.1 if i cannot seem to troubleshoot this mesh error by the end of the week. I will let you know if it runs on v2.1 instead of v2.2 thanks again Dmoore |
|
July 3, 2013, 16:35 |
|
#20 |
New Member
|
Ok so I have diagnosed my problem with SHM-
SolidWorks (a 3D modeling software) creates objects and saves as an stl format (for SHM to use) but fills the objects with zero volume. In fact, the only volume taken up is by the lines that define the edges. This results in what seems to be an 'Open' volume when in fact it does not exist in the first place. I would be curious to know if anyone has ever used SolidWorks to mesh with SnappyHex, and if they have successfully, they will be my hero |
|
Tags |
snappyhexmesh, surfacefeatureextraction |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Review: Reversed flow | CRT | FLUENT | 1 | May 7, 2018 06:36 |
Difference between External and Internal flow radiation problems | Kummi | FLUENT | 0 | April 10, 2018 04:06 |
[snappyHexMesh] SnappyHexMesh for internal Flow | vishwa | OpenFOAM Meshing & Mesh Conversion | 24 | June 27, 2016 09:54 |
[snappyHexMesh] snappyHexMesh and blockMesh for internal flow (leaking geometry?) | vaina74 | OpenFOAM Meshing & Mesh Conversion | 10 | November 20, 2014 10:14 |
Internal flow simulation BCs | SteveGoat | FLUENT | 0 | May 10, 2012 07:41 |