Not extruding boundary layer [SOLVED]
 

I'm trying to obtain a mesh using snappyHexMesh. I'm using "consolidated" settings (in the sense that these are settings that i often use without any problem).

But in this mesh I needed to create also baffle, therefore I did only one change to the settings:

Code:

---

allowFreeStandingZoneFaces true;  //before was false

---

As far as I understood this setting may give some problem with the mesh quality. Indeed I obtained:

Code:

---

Layer mesh : cells:25759574  faces:80125713  points:28557646
Cells per refinement level:
    0        249533
    1        1879
    2        6680
    3        22934
    4        251389
    5        589058
    6        602221
    7        560941
    8        16150180
    9        1398684
    10        4849433
    11        301205
    12        775437
Writing mesh to time constant
Wrote mesh in = 150.001 s.
Layers added in = 14717.6 s.
Checking final mesh ...
Checking faces in error :
    non-orthogonality > 65  degrees                        : 243
    faces with face pyramid volume < 1e-013                : 0
    faces with face-decomposition tet quality < 1e-015      : 2
    faces with concavity > 80  degrees                    : 2
    faces with skewness > 2  (internal) or 15  (boundary) : 0
    faces with interpolation weights (0..1)  < 0.05        : 0
    faces with volume ratio of neighbour cells < 0.01      : 1
    faces with face twist < 0.02                          : 0
    faces on cells with determinant < 0.001                : 0
Finished meshing with 248 illegal faces (concave, zero area or negative cell pyramid volume)
Finished meshing in = 35841.2 s.
End

---

But over a such a big mesh I hope they don't represent a problem.

The real problem is with BL:

Code:

---

Doing final balancing
---------------------

Writing 189374 added cells to cellSet addedCells
Writing 142659 faces inside added layer to faceSet layerFaces

Writing fields with layer information:
    nSurfaceLayers    : actual number of layers
    thickness        : overall layer thickness
    thicknessFraction : overall layer thickness (fraction of desired thickness)


patch        faces    layers  overall thickness
                                [m]      [%]
-----        -----    ------  ---      ---
DPE_FW        1297616  0        0        0     
DPE_Telaio    660614  0.181    0.000592  3.3   
DPE_RW        125248  0.491    0.00169  8.46   
DPE_MW        87040    0.00494  4.09e-006  0.0205 
DPE_FWheels  66032    0        0        0     
DPE_RWheels  66306    0        0        0     
DPE_Diffusore 65186    0.118    0.000225  1.25

---

I really don't understand what I'm doing wrong as I checked the dict many times and the mesh doesn't seem to have evident problems (exept for missing BL).

Can someone check if there are evident error in the snappyHexMeshDict I attached? Wherelse can the problem lie?

(I also uploaded here the log)

Hi !

Based on your SHMDict, from my point of view, to improve the layers coverage you can try to decrease the resolveFeatureAngle from the castellated phase to 15 degrees.

For the snapping phase try to activate multiRegionFeatureSnap.

And for the addLayers one, try to put nGrow to 0 because for my cases it has always produced a bad layer coverage onto the geometry.

Cheers,

Thank you for your suggestions!
...but my problems got worse :(

I increased some refinement parameter in addition to the changes you suggested. By doing so my CAD file has proved not to be watertight. Therefore I changed the STL and now it seems to be watertight.


Nevertheless snappy gets completrly stuck at the layer addition phase:
And then I get this error (that its pretty rare from what I see online):
I still managed to reconstruct the mesh of castellation and snapping phases. Everything seems really smooth and well defined.

And also with checkMesh it looks like there are no big problems:

What can I do next? Since I found few online resouce on that error message I have no clue on how to adress it.

Hi !

Really strange,by looking at this statement :

I checked on some SHM log files and the angle seems pretty high as for me this angle is 30 degrees most of the time.

I found in the fondation version code that this angle displayed (in bold) is linked to your featureAngle in the addLayers section and it is actually pretty high (250°) !



For me the limit is 180 degrees because there is no improvement above it and because it is related to other function maybe it crashes ?

so you can test with featureAngle less or equal to 180.

Cheers.

Thank you so much for your speedy reply!

I forgot to mention that I also had alreay lowered featureAngle at 180 deg.
In order to try your suggestion I tried to lower it further, setting it at 130 deg.

Therefore the "strange" part should now look more standard:
But I got the same error as before.

I uploaded the full log here and the updated dict.

Do you have any further suggestion?

P.S.: Do you think this can happen because of the new STL files? I tend to exclude that since the other two phases work well... but I don't know what to think...

To be sure it is the STL file have you done a ? Maybe it will help you.

I've just found this thread which is quite interesting for your error if you did not read it yet. It is talking about higher refinement level for edges or better tolerance for your CAD file.

https://www.cfd-online.com/Forums/op...ide-loops.html

Ok in these days our server is being used by someone else but I manage to run at least the checkMesh

I see big problems but I really don't know what can be the cause of such a bad quality, given the high settings I'm using.


Regarding the topic you linked me: I've already read it, I tried to increase some parameter but, as you can see from the dict, they are already pretty high (therefore I'm already at the limit of server resources).
Should I try to increase some setting even further or do you suggest something else?

To be honest I'm running out of ideas. :(
Maybe changing the decomposition method or drastically the version of OpenFOAM could solve this kind of problem.

Anyway, thanks for your help!

I'm posting a quick update if someone wants to share any other idea.
This is what I've done so far:

1. Imported my STL files in a website in order to fix them. This was certanly a good step forward because the resulting files were "approved" by surfaceCheck
2. I tried to mesh something with my personal PC (using the same STL files but obviously with lowered refinement settings and just 1 boundary layer). Everything worked smoothly despite the low quality of the mesh.
3. Up until now I used on the server an OpenFOAM version compiled for Windows whereas my PC runs Ubuntu. Therefore I thought that the problem lied there and I managed to start meshing on a Ubuntu server.
   Nevertheless, using high refinement settings, I obtain the same error also on this system. The only difference is that now the error is better described (but still unintelligible):
   
   Code:

   ---

   [9]
[9]
[9] --> FOAM FATAL ERROR:
[9] [9]    in file polyTopoChange/polyTopoChange/combineFaces.C at line 419.
[9]
FOAM parallel run aborting
[9]
[9] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[9] #1  Foam::error::abort() at ??:?
[9] #2  Foam::combineFaces::getOutsideFace(Foam::PrimitivePatch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&)[10]
[10]
[10] --> FOAM FATAL ERROR:
[10] Multiple outside loops:0()
[10]
[10]    From function static Foam::face Foam::combineFaces::getOutsideFace(const indirectPrimitivePatch&)
[10]    in file polyTopoChange/polyTopoChange/combineFaces.C at line 419.
[10]
FOAM parallel run aborting
[10]
[10] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[10] #1  Foam::error::abort() at ??:?
[10] #2  Foam::combineFaces::getOutsideFace(Foam::PrimitivePatch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:?
[9] #3  Foam::combineFaces::validFace(double, Foam::PrimitivePatch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:?
[10] #3  Foam::combineFaces::validFace(double, Foam::PrimitivePatch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:?
[9] #4  Foam::combineFaces::getMergeSets(double, double, Foam::HashSet<int, Foam::Hash<int> > const&) const at ??:?
[10] #4  Foam::combineFaces::getMergeSets(double, double, Foam::HashSet<int, Foam::Hash<int> > const&) const at ??:?
[9] #5  Foam::meshRefinement::mergePatchFacesUndo(double, double, Foam::List<int> const&, Foam::dictionary const&, Foam::List<int> const&) at ??:?
[10] #5  Foam::meshRefinement::mergePatchFacesUndo(double, double, Foam::List<int> const&, Foam::dictionary const&, Foam::List<int> const&) at ??:?
[9] #6  Foam::snappyLayerDriver::mergePatchFacesUndo(Foam::layerParameters const&, Foam::dictionary const&) at ??:?
[10] #6  Foam::snappyLayerDriver::mergePatchFacesUndo(Foam::layerParameters const&, Foam::dictionary const&) at ??:?
[10] #7  Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[9] #7  Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[10] #8  at ??:?
[9] #8  ?? in "/opt/openfoam6/platforms/linux64GccDPInt32Opt/bin/snappyHexMesh"
[10] #9  __libc_start_main in "/opt/openfoam6/platforms/linux64GccDPInt32Opt/bin/snappyHexMesh"
[9] #9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[10] #10  in "/lib/x86_64-linux-gnu/libc.so.6"
[9] #10  ? in "/opt/openfoam6/platforms/linux64GccDPInt32Opt/bin/snappyHexMesh"

   ---

Therefore changing the version of OF does not help, but I will try changing the decomposition method.


Just a final considerations after reading this comment (and in general the whole topic):
I think that there is nothing wrong in my STL files nor in my snappyHex settings per se, but probably the combination of both, at high refinements, generates that problem.

Unfortunately I cannot share my geometry but I hope that someone has some suggestions on how to avoid that behavior in general.

I think I managed to solve my problem. There were mainly 3 problems:

1. I didn't compute accurately the last layer dimension in comparison with the cell dimension. This was one the causes of the bad bl addition.
   My suggestion for everyone that will read this post is to perform only the snapping and castellation phases. Check the meshes and check accurately if the last bl thickness is smaller than the local cell dimension.
2. The multi-region mesh that I obtained was the cause of the Multiple outside loops:0() error. Running the splitMeshRegions command solved this but the quality of the mesh was still bad.
3. The thing that improved the quality of the mesh (in particular the multiple regions were not created anymore) is the modification of my geometry at the symmetry-plane.

In addition, I set an higher number of iterations both for the snapping and the layer addition phases. And this made checkMesh a little happier.

Just a note about this:
While trying to solve my problem, I found out this PDF where the following was reported:
I really don't know who is right since I don't have time to test. But still, I thought it was worthy to report this to you and to the readers of the thread.

Anyway, thank you again for your help!

I'm glad you've solved your problem !

Thanks for sharing this interesting paper.