[bastil]

Hi Group,

I have problems with a case with symmetry in snappyHexMesh. My geometry has free edges at the symmetry (y=0). These edges are exactly at the border of the initial hex-mesh created by blockMesh. SnappyHexMesh stands at:

Surface refinement iteration 5
------------------------------

Marked for refinement due to surface intersection : 2816 cells.

How to overcome this?

[mattijs]

Make your surface extend beyond the symmetry plane. Does the mesher hang? If so please create a testcase and file a bug report (in OpenFOAM-bugs).

[bastil]

Yes, the mesher hangs. I can get a mesh if I stay with refinements below level 5 everything works fine. As soon as my level gets 5 or greater the mesher hangs at Surface Refinement Iteration 5.

[bastil]

If I mirror my triSurface but leave the initial Hex-Mesh as it is I still have the same problems. I do not think it is related to this. I saw the tutorial has the same free edge situation at tyre contact patch.
Creating testcase is difficult - how can I find out why and where the mesher is hanging?

Thanks

[bastil]

I see I can get closer to the problematic areas by fitting refinement regions. Some regions of my geometry make the mesher hang up if going finer than level 4, others when going finer than level 5. Others have no problem... Process is quite slow - are there quicker ways to find problems?

Regards

[mattijs]

when it's hanging: gdb -pid XXXX

where XXXX is the pid of snappyHexMesh (printed in the header actually)

Inside gdb type 'where' and whatever else you normally do inside a debugger. Continue a bit ('cont' command?) and ctrl-C and see where you are now. Inside same loop?

You might want to compile autoMesh and snappyHexMesh with -DFULLDEBUG -g -O0 to get some more interesting info.

[eugene]

Please be aware that the mesher uses quite a bit of memory at the moment - somewhere around 3GB/million cells. This will go down in future, but for the time being it is very easy to run out of memory and for the machine to start swapping. You can work around this by running the meshing in parallel or installing more memory.

[bastil]

Eugene,

thanks for this hint. I was aware of that and I am definitely not running out of memory nor swapping.

Refiner is obviously hanging at certain parts of the surface. How can I find out more about the problems? I tried debug=1 but without any success.

[eugene]

Follow Mattijs' instructions and then when it hangs, you can hook gdb into the running process to find out where it is stuck:

gdb snappHexMesh PID

where

[bastil]

Thanks Matthijs, Eugene.

the mesher stands at the same position after waiting for about half an hour:

(gdb) where
#0 0x00002b3e3005a130 in Foam::List<foam::pointindexhit<foam::vector<double > > >::setSize ()
from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#1 0x00002b3e3271f51d in Foam::triSurfaceMesh::findLineAll () from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libmeshTools.so
#2 0x00002b3e3004f453 in Foam::refinementSurfaces::findAllHigherIntersectio ns ()
from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#3 0x00002b3e3004794d in Foam::meshRefinement::markSurfaceCurvatureRefineme nt ()
from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#4 0x00002b3e30049188 in Foam::meshRefinement::refineCandidates ()
from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#5 0x00002b3e2ffd6cd0 in Foam::autoRefineDriver::surfaceOnlyRefine ()
from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#6 0x00002b3e2ffd945f in Foam::autoRefineDriver::doRefine () from /home/brblo/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libautoMesh.so
#7 0x0000000000406036 in main ()

[bastil]

I have made some progress with that. I am able to work patch-wise now due to better Hypermesh import (thanks) and this helps a lot. So far I found two patches that makes snappyhexmesh hanging if level is larger than 4 (but there must be some more in this geometry). These patches are direct neighboors. Additionally, they are in close proximity to the bounding box of the initial hex-mesh. Maybe this is a problem. I will go on with this problem.