This is already implemented in my workflow but did not solve the issue for me unluckily :(
|
Same here. Additionally, this doesn't explain why meshing on a smaller number of cores is successful. If the surface mesh had problems, all meshing would suffer.
-Chris Quote:
|
1 Attachment(s)
Greetings to all!
@Chris: Quote:
Best regards, Bruno |
Bruno,
Quote:
Unfortunately, I haven't been able to reproduce it on a generic model that I can share here, but I just wanted to note that it is still a problem I see. Code:
(12): ERROR: dgraphFold2: out of memory (2) |
Greetings Brock,
Interesting... OK, then we might be able to do some trial and error debugging, by having a set of code changes that can give output relevant to debugging the issue. So please make sure you set a few copies of cases aside, where these bugs are reproducible, since the debugging code can then be tested on your side. But first, a few questions:
Bruno |
Shell mesh quality seems to be important for snappy
Hi there
Thanks for this enlightening thread. We do huge simulations with up to 150M cells. Of course, the meshing has to be done in parallel and with the same number of processors used for the simulation to avoid redistribution of the cells. From time to time we suffer the same error like you do. Code:
(20): ERROR: dgraphFold2: out of memory (2) Unfortunately there is not tool in OpenFOAM to optimize shell mesh quality or at least I don't know one. We handle all STL files in ANSA. Hope this helps a little bit. Cheers Fabian |
After spending a considerable time working on how STLs are produced, I can agree with Fabian. I rarely encounter this if surfaceCheck comes back with no errors. I actually got through ~300 4M cell meshes without an error (also OF2.3.X). I would love to see some tools built into OF that help clean up surfaces meshes, but I also understand that is a very difficult task.
I've also tried cfMesh, which seems to have fewer issues with bad surface geometries. If cfMesh works for your application and you're seeing these errors, it might be worth trying. |
Bug report created
All,
I've finally been able to reproduce these errors reliably (I've tried on three separate machines) on a somewhat small simple pipe model I can share. I'm hoping you all (and the developers) will be able to reproduce my errors. I created a bug report for it... http://www.openfoam.org/mantisbt/view.php?id=1792 If anyone with more OF code knowledge would like to take a hack at tracking it down, please go for it! Thanks again for everyone's help! |
Same problem with openFOAM2.4.0
I am facing the same problem with OF240. I can snappyHexmesh with 4 processors, but cannot do the same with 8. It just runs out of memory! Any fix yet?
|
shashank,
Per the bug report, we think the bug is in the thirdparty scotch decomposition library. Mattijs noted that he's heard that scotch 6.0.4 resolved some of these errors. However, I have been unsuccessful in getting scotch 6.0.4 to compile properly thus far. And judging by the comment in OpenFOAM-dev on commit 38415f8, it looks like OpenFOAM-dev hasn't been upgraded to 6.0.4 for the same reason. In any case, the workaround for me at the moment is to change the decomposition type to simple. This is annoying because you then have to specify the xyz decomps, but it's a workaround for now. Brock |
I worked around it using hierarchical decomposition. In my opinion, it has worked better than scotch for me.
|
Problem believed to be resolved
All, as of commit 1da3d4a in 2.4.x and commit e64a892 in dev, I can no longer reproduce this problem on my test models. Shout out to Henry for resolving my bug report and committing the code! Hopefully it's resolved for good.
|
Hello,
I have just got this error. Ubuntu 14.04 LTS Openfoam 2.4.0 x86_64 Base mesh number of cells 187k decomposition model scotch number of processors 8 Funny thing is I have been using this stl file for a couple of weeks and I didn't have any problem, later I just made the stl file a bit longer (it is a flat plate with something in the middle of the domain) and change its direction by Blender and received this error. Now I've solved it by using simple method and I thought it may be useful to write here. |
Quote:
Code:
// If local number of cells is >= maxLocalCells on any processor |
Still a issue in 2023!
Been running into this issue a lot with 10-30M cell parallel cases.
After looking into it I'm relatively sure it has something to do with the angles between triangles of the stl file, includedAngle for surfaceFeatureExtract, and resolveFeatureAngle in castellatedMeshControls for snappyHexMesh. My guess would be that in some cases these angles create a loop or logic error or something that causes the generation to crash. Most likely to occur if all three of those angles are close to each other. And seems to work better (crash less) the further they are spaced out, like 5-15deg from each other. |
All times are GMT -4. The time now is 19:32. |