|
[Sponsors] |
[snappyHexMesh] Adding layers distorts internal mesh |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
November 6, 2023, 10:58 |
Adding layers distorts internal mesh
|
#1 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
I am finding that if I add a thick layer on one of the domain boundaries, SHM makes a real mess of the mesh at the other surfaces, as it shrinks the internal mesh to make way for the layer. In the example below, the mesh at the top of the cube is stretched horribly. Is there any way to control this better (other than to use a thinner layer)? I couldn't see anything in the snappyHexMeshDict controls ... any suggestions would be welcomed.
Code:
/*--------------------------------*- C++ -*----------------------------------*\ ========= | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox \\ / O peration | Website: https://openfoam.org \\ / A nd | Version: dev \\/ M anipulation | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object snappyHexMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // castellatedMesh true; snap true; addLayers true; geometry { domain { type triSurfaceMesh; file "cube.stl"; name cubeSTL; // name of this surf inside SHM regions { top { name cube_top ;} // STL patch name and final name of the patch sides { name cube_sides ;} bottom { name cube_bottom ;} } } }; castellatedMeshControls { maxLocalCells 1000000; //default 100000; maxGlobalCells 5000000; //default 2000000; minRefinementCells 10; maxLoadUnbalance 0.10; nCellsBetweenLevels 5; //feature edge refinement - eMesh read from constant/triSurface features ( { file "cube.eMesh"; level 1; } ); //surface refinement refinementSurfaces { cubeSTL { level (1 1); regions { top { level (1 1); patchinfo { type wall; } } sides { level (1 1); patchinfo { type wall; } } bottom { level (1 1); patchinfo { type wall; } } } } } resolveFeatureAngle 30; //volume refinement refinementRegions { } //other mesh parameters locationInMesh (0 0 2); allowFreeStandingZoneFaces true; } snapControls { nSmoothPatch 3; tolerance 2.0; nSolveIter 30; nRelaxIter 5; nFeatureSnapIter 10; implicitFeatureSnap false; explicitFeatureSnap true; multiRegionFeatureSnap false; } addLayersControls { relativeSizes false; firstLayerThickness 0.02; thickness 0.2; layers { Zneg {nSurfaceLayers 5;} } minThickness 0.005; nGrow 0; featureAngle 160; slipFeatureAngle 30; nRelaxIter 5; nSmoothSurfaceNormals 1; nSmoothNormals 3; nSmoothThickness 10; maxFaceThicknessRatio 0.5; maxThicknessToMedialRatio 0.3; minMedianAxisAngle 90; nBufferCellsNoExtrude 0; nLayerIter 50; nRelaxedIter 20; } meshQualityControls { #include "meshQualityDict" } writeFlags ( scalarLevels layerSets layerFields ); mergeTolerance 1e-6; |
|
November 7, 2023, 02:25 |
|
#2 |
Senior Member
M
Join Date: Dec 2017
Posts: 644
Rep Power: 12 |
oO, it appears you are running the Foundation version, right?
I use the ESI version for meshing and cannot remember seeing it shift this way at another boundary so far away and parallel to it. Any chance you can try the same with ESI OpenFOAM? There is also an additional mesh shrinker available there, which behaves differently from the default one (that is probably used here and somewhat similar to the ESI default). You could also provide us the stl and I can check for myself in the evening. |
|
November 7, 2023, 03:49 |
|
#3 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
Great suggestion - I will try it out this afternoon and let you know how I get on. Many thanks.
|
|
November 7, 2023, 03:49 |
|
#4 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
I don't see why it would make a difference, but you may try to explicitly define 0 layers on your cube top surface to see if it affects the mesh.
Long time ago I had a really confusing issue on a mesh and it was related to specifying 0 layers on a surface or leaving it undefined, in a place where it wasn't supposed to make a difference. So I guess it would be worth trying, just to make sure. |
|
November 7, 2023, 03:50 |
|
#5 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
Cheers Yann - I'll give that a go this afternoon as well. Stand by!
|
|
November 7, 2023, 04:00 |
|
#6 | |
Senior Member
M
Join Date: Dec 2017
Posts: 644
Rep Power: 12 |
Quote:
Thats the super expert knowledge here I am curious if it helps. It if does not make a difference, you can try to prescribe 1 layer on the top with a region-specific firstLayerThickness of your "normal cell size" (you can prescribe these parameters globally like you did, or for each region separately by adding them again inside the specific region{ ... } part). Code:
layers { cube_top { nSurfaceLayers 1; firstLayerThickness 0.05; //or whatever the size is } Zneg {nSurfaceLayers 1;} } |
||
November 7, 2023, 08:29 |
|
#7 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
Wow - I tried Yann's suggestion first, since it was the easiest/quickest to try:
Code:
layers { Zneg {nSurfaceLayers 5;} cube_top {nSurfaceLayers 0;} } I'll try the ESI version later on this afternoon, just to complete the story. But in the meantime - many thanks to you both for your suggestions. |
|
November 7, 2023, 09:08 |
|
#8 | |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
Quote:
Now what is going on... As I understand it : specifying 0 layers ensure the patch will not be affected by the layer addition. It's a way to freeze the patch. Not specifying anything means the patch might be affected by the layer addition, even if there is no layer to be inserted on this patch. The best example for that would be the side walls of your cube. You didn't specify anything for those patches in the layers section, but they are affected by the layer addition on Zneg (see screenshot) If you specify 0 layers on those walls, it will be frozen and the layers will get killed close to the wall. Now concerning your cube top face it is pretty hard to now why you get this result. I can only guess it might be a side effect of the mesh morphing on the side walls and surrounding mesh. So whether your should define a number of layers or not depends on what behavior to want on the patch. |
||
November 7, 2023, 09:58 |
|
#9 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
That's brilliant. I tested it with another case, for a cylinder on a surface ("ground"):
- if I do not specify anything for the sides and top of the cylinder, the mesh shrinkage really mangles the interior mesh, corrupting the snapping to the cylinder (see pics 1 & 2); - if I explicitly specify 0 layers on the sides and top of the cylinder I get some degenerate cells at the bottom of the cylinder, at the point where the cylinder meets the ground (see pic 3) - and if I explicitly specify 0 layers on the top alone I get a perfect mesh (see pic 4) |
|
November 12, 2023, 10:22 |
|
#10 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 670
Rep Power: 14 |
Just a quick update on this one - I tried snappyHexMesh under v2112, and got exactly the same behaviour with the same setup ... there are clearly more options in the v2112, but I stuck with the default shrinkage model and just read the notes in the annotated SHM dictionary, and this prompted me to try adding the following to the addLayersControls section:
Code:
nMedialAxisIter 10; |
|
November 13, 2023, 03:03 |
|
#11 |
Senior Member
M
Join Date: Dec 2017
Posts: 644
Rep Power: 12 |
Interesting. I never touched this and wouldn't have either in this situation. Also I am finding the doc weird one this, its a num of iteration kind of parameter but seems to spatially limit the zone of influence of the distortion. How do I know the extent of this region by the number of iterations? Ominous!
|
|
November 13, 2023, 03:32 |
|
#12 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
Thanks for your feedback Tobermory, I would not have thought to use this parameter for this specific issue.
Now I wonder what kind of influence it can have on other cases. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
2 ways to mesh a multiRegion case - one works, the other fails | boffin5 | OpenFOAM Running, Solving & CFD | 16 | March 27, 2023 12:58 |
[snappyHexMesh] Holes in internal mesh when adding boundary layer snappyHex | otaolafr | OpenFOAM Meshing & Mesh Conversion | 3 | February 8, 2021 08:19 |
[snappyHexMesh] SnappyHexMesh no layers and no decent mesh for complex geometry | pizzaspinate | OpenFOAM Meshing & Mesh Conversion | 1 | February 25, 2015 07:05 |
[snappyHexMesh] Adding layers goes wrong with SnappyHexMesh | Elise | OpenFOAM Meshing & Mesh Conversion | 1 | April 22, 2013 02:32 |
[snappyHexMesh] snappyHexMesh won't work - zeros everywhere! | sc298 | OpenFOAM Meshing & Mesh Conversion | 2 | March 27, 2011 21:11 |