|
[Sponsors] |
[snappyHexMesh] snappyHexMesh - 90° edges problem |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
September 24, 2021, 07:43 |
snappyHexMesh - 90° edges problem
|
#1 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hello everyone,
I am learning SHM to generate a mesh of a simple reactor. It is a cylinder, which has an inclination at the bottom, an inflow at the top and an outflow at the side. I used sketchup for the geometry. I have created stl for each surface (inflow, outflow, walls, bottom, top) and also for the whole volume (reactor).Then I proceeded: -BlockMesh -SurfaceFeatureExtract -SnnapyHexMesh SurfaceFeatureExtract Code:
inflow.stl { // How to obtain raw features (extractFromFile || extractFromSurface) extractionMethod extractFromSurface; // Mark edges whose adjacent surface normals are at an angle less // than includedAngle as features // - 0 : selects no edges // - 180: selects all edges includedAngle 150; subsetFeatures { // Keep nonManifold edges (edges with >2 connected faces) nonManifoldEdges no; // Keep open edges (edges with 1 connected face) openEdges yes; } // Write options // Write features to obj format for postprocessing writeObj yes; } outflow.stl { // How to obtain raw features (extractFromFile || extractFromSurface) extractionMethod extractFromSurface; // Mark edges whose adjacent surface normals are at an angle less // than includedAngle as features // - 0 : selects no edges // - 180: selects all edges includedAngle 150; subsetFeatures { // Keep nonManifold edges (edges with >2 connected faces) nonManifoldEdges no; // Keep open edges (edges with 1 connected face) openEdges yes; } // Write options // Write features to obj format for postprocessing writeObj yes; } top.stl { // How to obtain raw features (extractFromFile || extractFromSurface) extractionMethod extractFromSurface; // Mark edges whose adjacent surface normals are at an angle less // than includedAngle as features // - 0 : selects no edges // - 180: selects all edges includedAngle 150; subsetFeatures { // Keep nonManifold edges (edges with >2 connected faces) nonManifoldEdges no; // Keep open edges (edges with 1 connected face) openEdges yes; } // Write options // Write features to obj format for postprocessing writeObj yes; } bottom.stl { // How to obtain raw features (extractFromFile || extractFromSurface) extractionMethod extractFromSurface; // Mark edges whose adjacent surface normals are at an angle less // than includedAngle as features // - 0 : selects no edges // - 180: selects all edges includedAngle 150; subsetFeatures { // Keep nonManifold edges (edges with >2 connected faces) nonManifoldEdges no; // Keep open edges (edges with 1 connected face) openEdges yes; } // Write options // Write features to obj format for postprocessing writeObj yes; } walls.stl { // How to obtain raw features (extractFromFile || extractFromSurface) extractionMethod extractFromSurface; // Mark edges whose adjacent surface normals are at an angle less // than includedAngle as features // - 0 : selects no edges // - 180: selects all edges includedAngle 150; subsetFeatures { // Keep nonManifold edges (edges with >2 connected faces) nonManifoldEdges no; // Keep open edges (edges with 1 connected face) openEdges yes; } // Write options // Write features to obj format for postprocessing writeObj yes; } Code:
geometry { inflow.stl { type triSurfaceMesh; name inflow; } outflow.stl { type triSurfaceMesh; name outflow; } top.stl { type triSurfaceMesh; name top; } bottom.stl { type triSurfaceMesh; name bottom; } walls.stl { type triSurfaceMesh; name walls; } reactor.stl { type triSurfaceMesh; name reactor; } } //// Optional: avoid patch-face merging. Allows mesh to be used for //// refinement/unrefinement mergePatchFaces off; // default on // 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 1000000; //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 10; // 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; //1; // 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 "inflow.eMesh"; level 0; } { file "outflow.eMesh"; level 0; } { file "top.eMesh"; level 0; } { file "bottom.eMesh"; level 0; } { file "walls.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 { inflow { // Surface-wise min and max refinement level level (0 0); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } outflow { // Surface-wise min and max refinement level level (0 0); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } top { // Surface-wise min and max refinement level level (0 0); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } bottom { // Surface-wise min and max refinement level level (4 4); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } walls { // Surface-wise min and max refinement level level (0 0); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } } // Resolve sharp angles resolveFeatureAngle 0;// 30; // 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 { reactor { mode distance; levels ((2 2)); } } // 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 0 0.7); // 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 3; //- Relative distance for points to be attracted by surface feature point // or edge. True distance is this factor times local // maximum edge length. tolerance 2.0; //- Number of mesh displacement relaxation iterations. nSolveIter 30; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 5; // Feature snapping // //- Number of feature edge snapping iterations. // // Leave out altogether to disable. // nFeatureSnapIter 30; //10; // // //- Detect (geometric only) features by sampling the surface // // (default=false). // implicitFeatureSnap false; // // //- Use castellatedMeshControls::features (default = true) // explicitFeatureSnap true; // // //- Detect points on multiple surfaces (only for explicitFeatureSnap) // multiRegionFeatureSnap false; } Any idea? thank you very much! |
|
September 29, 2021, 10:08 |
|
#2 | ||
Member
Join Date: May 2017
Posts: 31
Rep Power: 9 |
Quote:
You can solve this by making a second snappyHexMeshDict, and splitting the surfaces between them. So in system/snappyHexMeshDict1, have Code:
geometry { inflow.stl { type triSurfaceMesh; name inflow; } outflow.stl { type triSurfaceMesh; name outflow; } // removed top and bottom walls.stl { type triSurfaceMesh; name walls; } reactor.stl { type triSurfaceMesh; name reactor; } } Code:
geometry { top.stl { type triSurfaceMesh; name top; } bottom.stl { type triSurfaceMesh; name bottom; } } Code:
snappyHexMesh -dict system/snappyHexMeshDict1 snappyHexMesh -dict system/snappyHexMeshDict2 Quote:
Try reducing nSmoothPatch (with nSmoothPatch greater than 0, it modifies the surface before snapping to try to make it smoother, setting it to 0 forces it to use the original surface you've provided - this might help sharpen the corners as well) Try increasing tolerance (if tolerance is too low, it'll leave points where they are instead of snapping them onto the surface, if they're too far away) Try increasing nSolveIter, nRelaxIter, and nFeatureSnapIter (It'll try more times to do the snapping properly before giving up - and running out of iterations often leaves the steps you're seeing, where it couldn't snap well enough by the end of the iteration limit so just leaves you with the stair-like castellated mesh) That last one might make it take a lot longer - test it on a much lower-resolution mesh first to find settings that seem to work, then copy the settings over to your real mesh Hope this helps! |
|||
September 29, 2021, 12:02 |
|
#3 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
no one? =(...
Could it be a problem coming from the geometry? For example, to construct the cylinder in sketchup I first had to define a circle with a limited number of sides (the maximum sides I could give was 600, considering that the radio is 1 m approx.) Or is it something Im missing in snappyHexMesh...? Thanks in advance! |
|
September 29, 2021, 12:45 |
|
#4 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,220
Rep Power: 28 |
Hi,
In your snappyHexMeshDict, the Feature snapping section is commented. This part is supposed to deal with feature lines (edges). Code:
// Feature snapping // //- Number of feature edge snapping iterations. // // Leave out altogether to disable. // nFeatureSnapIter 30; //10; // // //- Detect (geometric only) features by sampling the surface // // (default=false). // implicitFeatureSnap false; // // //- Use castellatedMeshControls::features (default = true) // explicitFeatureSnap true; // // //- Detect points on multiple surfaces (only for explicitFeatureSnap) // multiRegionFeatureSnap false; The explicitFeatureSnap flag allow to use the eMesh files created with surfaceFeatureExtract to snap your mesh on the edges of your geometry. So you should probably start by uncommenting this, run again snappyHexMesh and let us know if it solved your issue. Cheers, Yann |
|
September 29, 2021, 13:05 |
|
#5 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Dear Yann,
Thank you very much for replying. Unfortunately I tried uncommenting all the Feature snapping section and running everything again, but the result looks exactly the same... means that maybe I have an issue with the e.mesh files? Thanks in advance! |
|
September 29, 2021, 13:27 |
|
#6 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,220
Rep Power: 28 |
You can use the surfaceFeatureConvert utility to convert your eMesh files to obj:
Code:
surfaceFeatureConvert constant/triSurface/yourFile.eMesh youOutputFile.obj Yann |
|
October 1, 2021, 05:48 |
|
#7 |
Member
Join Date: May 2017
Posts: 31
Rep Power: 9 |
||
October 1, 2021, 10:55 |
|
#8 | |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Dear sqek,
thank so much for your detailed answer . Your answer didnt appear until today, weird!. If I understand well, you suggest to divide the snappyHexMeshDict in 2, one with the top and bottom and the other with inflow, outflow and wells. In addition, I should "enlarge" the cylinders at the well.stl to ensure that it will then be cut at the correct angle. Should both snappyHexMeshDict files contain the reactor.stl (the whole geometry) in the geometry section?, or is it enough that its mention only in snappyHexMeshDict1 as you wrote it in your answer. I enlarged the cylinders of the wall.stl and separated the snappyHexMeshDict (snappyHexMeshDict1 and snappyHexMeshDict2) as suggested. I run first: Quote:
I provide you some pictures of my geometry and also the simulation where it got stuck. Thank you very much |
||
October 1, 2021, 11:00 |
|
#9 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Dear Yann,
I used the surfaceFeatureConvert utility and took a look at the edges. I think they are looking fine (see e.mesh in attachments) I also provide you more pictures of my geometry. Any idea? Thank you! |
|
October 1, 2021, 11:44 |
|
#10 | |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,220
Rep Power: 28 |
Hi Troth,
Quote:
How many cells do you have in your final mesh? Since you did not post you full snappyHexMeshDict, do you also extrude layers on your walls? If yes, can you run a test with "addLayers false;" ? Did you modify the default mesh quality parameters? I would also comment the mergePatchFaces flag and set the resolveFeatureAngle back to 30. If you run another test, please post the snappyHexMesh log file so we can have a look at it. Yann |
||
October 1, 2021, 15:41 |
|
#11 | |
Member
Join Date: May 2017
Posts: 31
Rep Power: 9 |
Quote:
It looks like you're using the reactor geometry from reactor.stl in refinementRegions - you probably want to only refine everything once, so snappyhexmeshdict1 has reactor.stl and refinementRegions, snappyhexmeshdict2 doesn't need it in the geometry and has an empty entry for refinementRegions (including unneeded files in the geometry doesn't cause any problems though - it only does something if theres a refinementRegion/refinementSurface with the same name) With it getting stuck: is your extended cylinder closed (as in does it have closed ends?) or does it extend outside of the mesh? In each snappyHexMeshDict, you want the collection of surfaces you specify (in geometry and refinementSurfaces) to topologically split the mesh - so you can't go from inside to outside without crossing a surface. If there's a gap/hole somewhere, it won't know which cells to keep and which to get rid of, and if its refining and keeping the entire base mesh that could be why its stopping. Roughly how many cells are you aiming for? The screenshot of the log you posted says 10 million points, which seems like a lot for something you're still experimenting with - maybe make a copy with a much coarser initial mesh (lower cell count by a factor of 10 in each direction perhaps, to get ~10k rather than 10 million), to test on - that way it'll take much less time to snap and you can try different things quicker |
||
October 4, 2021, 10:32 |
|
#12 | |||
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hi Yann, thanks again for your reply.
My mesh has 1.6 M cells. Quote:
Quote:
Quote:
Thank you very much! |
||||
October 4, 2021, 12:27 |
|
#13 | |||
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hi sqek, thanks a lot for taking the time to answer me.
Unfortunately, Im just starting with snappyHexMesh and I have lot of questions about your comment, which are perhaps quite basic . Quote:
Quote:
Quote:
If my eMesh files are looking alright, do you still think that the problem should be solved by making longer the cylinder?...(in my other answer I posted screenshot of my eMesh) Thanks again for taking the time to answer and explain |
||||
October 5, 2021, 06:56 |
|
#14 | |
Member
Join Date: May 2017
Posts: 31
Rep Power: 9 |
Quote:
I've put together a quick simplified demo case, and got some screenshots attached here the green surfaces are stls In the first one, the ends of the open cylinder extend past the original blockmesh, so the boundary of the blockmesh closes it - basically, you can't get from the inside to the outside of the cylinder by moving point-to-point along the mesh, without crossing it In the second one, the first snappyhexmeshdict has made a cylinder and cut away the rest, and the end stls are shown In the third one, the second snappyhexmeshdict has cut the ends off the mesh hopefully this explains it better than another wall of text would And if you decrease the numbers in your blockmeshdict (assuming you're using blockmesh for the initial background mesh?) by a bit, it'll take seconds to run rather than minutes, so you can adjust settings faster and get near-instant feedback on whether its worked |
||
October 6, 2021, 05:19 |
|
#15 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,220
Rep Power: 28 |
Hi Troth,
Would it be possible for you to share your case here, including your STL files so we can have a closer look? Yann |
|
October 11, 2021, 13:00 |
|
#16 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hi Sqek,
Sorry for the late response, I haven't had time to look at it before... Thank you very much for explaining so clearly, now I do understand what you were saying. Thanks!! I am going to run an example similar to the one you made, to test if your suggestion works for me and I'll post the results, but it comes to my mind one small question. For the first step, did you use surfaceFeatureExtract to generate the cylinder.emesh? if this cylinder edges are outside the blockMesh, isn't it problematic?... Thanks in advance!! |
|
October 11, 2021, 13:19 |
|
#17 | |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Quote:
yes of course. Here I attach the case. Because of the size, I had to separate the geometry and upload the reactor geometry (total volume) in a separate Zip (so this reactor.stl comes inside the triSurface folder with the rest of the stl files). I also had to eliminate the polyMesh, eMesh and extendedFeatureEdgeMesh since it was too heavy but I supposed it's not a problem since the blockMeshDict, and surfaceFeatureExtractDict are incorporated. I know that the mesh does not close in the outflow pipe, but I want to solve first the edge problem and then fix that (I guess with higher refinement should solved). Thank you ver much for your time! |
||
October 11, 2021, 14:45 |
|
#18 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,220
Rep Power: 28 |
Hi Troth,
Thank you for uploading your case. I did run it and it seems the issue is related to the fact you are meshing independent surfaces in surfaceRefinement. If you use the reactor.stl instead, the snapping works fine with your current settings. I uploaded a screenshot, and here is the snappyHexMeshDict: Code:
geometry { reactor.stl { type triSurfaceMesh; name reactor; } } // 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 1000000; //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 10; // 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 1; // 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 "reactor.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 { reactor { // Surface-wise min and max refinement level level (0 0); // Optional specification of patch type (default is wall). No // constraint types (cyclic, symmetry) etc. are allowed. } } Doing so, you loose the surfaces names in your geometry and you end up with one single patch named "reactor" for your whole geometry. You can solve this issue by naming and concatenating your surfaces into one single STL file. This way you can get a proper snapping AND get your patches right. There must be resources about that on the internet or right here on the forum but we can elaborate about this later if you need. Cheers, Yann Last edited by Yann; October 12, 2021 at 09:19. Reason: Typo |
|
October 12, 2021, 06:29 |
|
#19 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hi Yann,
Thank you!! I just run it as you did and it finally works properly! . I did it that way, since I saw many tutorials on youtube where they separated the surfaces in different stl, I thought it was the best way to do it. Anyway, I'm going to name the surfaces in a single stl as you suggest. Thank you very much for your big help! Greetings, Troth |
|
October 22, 2021, 06:28 |
|
#20 |
New Member
troth
Join Date: May 2021
Posts: 19
Rep Power: 5 |
Hello again,
I think I proceed as suggested but I'm stuck again...
Code:
geometry { reactor.stl { type triSurfaceMesh; name reactor; regions { inflow { name inflow; } outflow { name outflow; } top { name top; } bottom { name bottom; } walls { name walls; } } } }; // 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 1000000; //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 10; // 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 1; // 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 "reactor.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 { reactor { level (2 2); regions { inflow { level (1 1); patchInfo { type wall; } } outflow { level (1 1); patchInfo { type wall; } } top { level (1 1); patchInfo { type patch; } } bottom { level (1 1); patchInfo { type patch; } } walls { level (1 1); patchInfo { type patch; } } } } } // Resolve sharp angles resolveFeatureAngle 30; //0; // 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 { } I don't know how else I can try to do it since I need to have the different patches defined to set the different refinements and later define the boundary conditions...I attached the case. any idea? Thank you very much! |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[snappyHexMesh] snappyHexMesh <-> dynamicMeshDict problem with protected cells | Billy_16 | OpenFOAM Meshing & Mesh Conversion | 2 | November 21, 2020 04:34 |
[snappyHexMesh] snappyHexMesh does not create any mesh except one for the reference cell | Arman_N | OpenFOAM Meshing & Mesh Conversion | 1 | May 20, 2019 18:16 |
[snappyHexMesh] snappyHexMesh inclinced surface snapping problem | Swift | OpenFOAM Meshing & Mesh Conversion | 19 | January 18, 2017 05:42 |
[snappyHexMesh] sHM layer process keeps getting killed | MBttR | OpenFOAM Meshing & Mesh Conversion | 4 | August 15, 2016 04:21 |
[snappyHexMesh] SnappyHexMesh in Parallel problem | swifty | OpenFOAM Meshing & Mesh Conversion | 10 | November 6, 2015 05:40 |