SnappyHexMesh Problem
 

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 4.1 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 4.1
Exec : snappyHexMesh -overwrite
Date : Apr 11 2019
Time : 18:31:43
Host : "oscae03"
PID : 24312
Case : /home/theuser/Desktop/MTC101-OPNew
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Read mesh in = 0.37 s

Overall mesh bounding box : (-8.6625 -4.025 -5.968) (4.8125 0 5.2695)
Relative tolerance : 1e-06
Absolute matching distance : 1.80016e-05

Reading refinement surfaces.
Read refinement surfaces in = 0.77 s

Reading refinement shells.
Read refinement shells in = 0 s

Setting refinement level of surface to be consistent with shells.
Checked shell refinement in = 0 s

Reading features.
Read edgeMesh MTC101.eMesh
points : 3027
edges : 2428
boundingBox : (-0.005 -0.1649 0.0001) (1.8742 0.0623 0.2553)

Refinement level according to distance to "MTC101.eMesh" (3027 points, 2428 edges).
level 0 for all cells within 0 metre.
Read features in = 0.01 s


Determining initial surface intersections
-----------------------------------------

Edge intersection testing:
Number of edges : 4452919
Number of edges to retest : 4452919
Number of intersected edges : 18657
Calculated surface intersections in = 9.77 s

Initial mesh : cells:1406244 faces:4452919 points:1642092
Cells per refinement level:
0 1406244

Adding patches for surface regions
----------------------------------

Patch Type Region
----- ---- ------
hull:

6 wall hull

Added patches in = 0.09 s

Selecting decompositionMethod none
Layer thickness specified as final layer and expansion ratio.

Refinement phase
----------------

Found point (-0.7 0 0) in cell 968430 on processor 0

Feature refinement iteration 0
------------------------------

Marked for refinement due to explicit features : 0 cells.
Determined cells to refine in = 23.01 s
Selected for feature refinement : 0 cells (out of 1406244)
Stopping refining since too few cells selected.


Surface refinement iteration 0
------------------------------

Marked for refinement due to surface intersection : 0 cells.
Determined cells to refine in = 0.09 s
Selected for refinement : 0 cells (out of 1406244)
Stopping refining since too few cells selected.


Removing mesh beyond surface intersections
------------------------------------------

Found point (-0.7 0 0) in global region 0 out of 2 regions.
Keeping all cells in region 0 containing point (-0.7 0 0)
Selected for keeping : 1406244 cells.
Edge intersection testing:
Number of edges : 4452919
Number of edges to retest : 0
Number of intersected edges : 18657

Shell refinement iteration 0
----------------------------

Marked for refinement due to distance to explicit features : 0 cells.
Marked for refinement due to refinement shells : 0 cells.
Determined cells to refine in = 4.5 s
Selected for internal refinement : 0 cells (out of 1406244)
Stopping refining since too few cells selected.


Dangling coarse cells refinement iteration 0
--------------------------------------------

Determined cells to refine in = 0.05 s
Selected for refinement : 21120 cells (out of 1406244)
hexRef8 : Dumping cell as obj to "/home/theuser/Desktop/MTC101-OPNew/cell_806418.obj"


--> FOAM FATAL ERROR:
cell 806418 of level 0 uses more than 8 points of equal or lower level
Points so far:8(88477 89337 836388 836603 876171 876369 915253 915640)

From function Foam::labelListList Foam::hexRef8::setRefinement(const labelList&, Foam::polyTopoChange&)
in file polyTopoChange/polyTopoChange/hexRef8/hexRef8.C at line 3701.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::hexRef8::setRefinement(Foam::List<int> const&, Foam::polyTopoChange&) at ??:?
#3 Foam::meshRefinement::refine(Foam::List<int> const&) at ??:?
#4 Foam::meshRefinement::balanceAndRefine(Foam::strin g const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
#5 Foam::snappyRefineDriver::danglingCellRefine(Foam: :refinementParameters const&, int, int) at ??:?
#6 Foam::snappyRefineDriver::doRefine(Foam::dictionar y const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
#7 ? at ??:?
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? at ??:?
Aborted (core dumped)


Hello, im new with openfoam solver. When i run my solver im always got snappyhex mesh error as shown above. Can someone share their expertise how to fix this... Tq in advanced for helping me...


Faiz

Hello Faiz,

snappyHexMesh needs a background hex mesh to start with. Usually, this initial mesh is created with blockMesh.

In your log file, snappyHexMesh complains about a cell having more than 8 points, which should not happen at this stage since the initial mesh is supposed to be purely hex mesh.
So it means something is wrong with your initial mesh.

Before running snappyHexMesh, you should run blockMesh to generate a clean initial hex mesh.

This error typically happens when you run blockMesh + snappyHexMesh a first time, then try to run again snappyHexMesh without executing blockMesh before. In this case snappyHexMesh will start with the old mesh as a starting mesh and will print the error you got.

Yann

Hi Yan,

Tq for sharing info. Actually i got this problem when i tried to change domain (vertices) in blockMeshDict. To begin with, the original domain quiet large then i re-scale into smaller size. Fyi, i run DTCHull simulation solver. Hope you can give me more enlighten about my problem.

Hello Faiz,

I had the same error when I used a blockMesh with a tube which I connected via MergePatchPairs to a box.

I think I could load the cells who "use more than 8 points of equal or lower level" to paraView and have a look where are the problematic areas in the mesh. When executing SnappyHexMesh one additional folder with those cells is generated. I do not remember the name, maybe another Foamer does.

Also I had a look at this thread when I searched the error:
https://www.cfd-online.com/Forums/op...-problems.html

In the end I ended up changig my geometry, but changing the refinement level did definitely reduce the cells with errors.
Hopefully this helps a bit!

Tq stefanie for the info. I will try the solution and update whether it success or not. The solution was to reduce nobetweencell in the snappyhexmeshdict right? Correct me if i mistake.

Yes, nBetweenCellLevels.

But I got more information from visualising error-Cells in the Mesh with ParaView.

Do you execute CheckMesh after every (seemingly successful) try?

Hello Faiz,

There are several things you can do to try to find some hints about the source of your problem:

1. Check the log files of every step, chronologically. If one step failed, the next ones will probably fail too. You have to solve the first error in order to move to the next step. (Since you modified your blockMeshDict, what does the log.blockMesh file say?)
2. After modifying your blockMeshDict and running blockMesh, load the mesh in paraView and open the geometry's STL. This will allow you to verify if everything is fine with the blockMesh mesh (since this is your starting point for snappyHexMesh) and if your mesh and STL are properly positioned.
3. These 2 first steps will allow you to make sure everything is done properly before starting snappyHexMesh. If it is and you still get the same error with snappyHexMesh, you can visualize the cell(s) responsible for the error, as suggested by Stefanie. In the log file you have posted, it says :
   Code:

   ---

   hexRef8 : Dumping cell as obj to "/home/theuser/Desktop/MTC101-OPNew/cell_806418.obj"

   ---

   You can open the file "cell_806418.obj" in paraview, in addition to your mesh and geometry, to see where is located the cell. It might help your to understand why there is a problem in this zone.

You may have done these things before and I don't know if it will allow you to find the cause of your problem, but this is a good practice to avoid being stuck because of a simple error.

You can post your log files and/or images here if you need some help.

Tq stefanie n yan.

Im really aappreciate ur help. Im already solved the error. The error due to toposetdict that contain bigger box than the blockmesh itself. Thus by editing the box in toposetdict help me solved the error. But then new problem come up. Something that relate to morph iteration: patchdisplacement cannot find nearest ...... i forgot. Later i update the log from the snappyhexmesh. Tq guys again

Hi all,

Just another possibility to find the error, it is still a frustration for anyone.
Usually snappy will give you an error of exactly which cells causes the problem. Then this cell is created as an .obj file, allowing you to plot it in paraview, simply by selecting "Open" in the "files" dropdown menu, select the cell and voila (you might have to hide the internal mesh from the original .foam file you have open to actually see where the cell is). This is what several others have already suggested, and it works quite good.

In my case, I had a topoSet dictionary specifying a refinement box intersecting exactly that cell and caused trouble. My solution was simply to use the refinementregions already inherent in snappy.

Hope this helps anyone who might have these problems.

Happy foaming

snappyHexMesh] SnappyHexMesh Problem
 

Hai @ Rasmusiwersen
What i understand from your suggestion is refinement by toposet is not done. refineregion in snappy was only used??
I am right?
If wrong please correct me
Waiting for a reply
Thank you

Hello

Thank you for your question. I must admit, since it hsa been a while since i had this problem, that i don't exactly recall where the problem was. I am quite sure the topoSet does not use snappyHexMeshDict to define regions, rather than a topoSetDict.

My suggestion was merely to use snappy in stead of toposet. This was at least a possibility in my case, but it might not be the solution you are looking for in your project.

Hope this helps.