snappyHexMesh sticking point
Hi all,
I've got what seems to be a rather specific problem as I've done a bit of searching and can't find anything that's similar. I'm running a slightly modified case of the turbine_siting tutorial with a different terrain model. During the snappyHexMesh process it seems to get to the 'Doing final balancing' stage and then freezes with the last output being 'Found 0 zones faces to keep together.'. I've included my sHM log below. The strange thing is I have had the exact same case file running with the only difference being that I have rotated the terrain to simulate different wind directions. So far I've run the case file for 4 directions each at 10 velocities, N, NW, W and SW but on the S direction I am having this problem. Code:
/*---------------------------------------------------------------------------*\ |
Greetings Andrew,
I don't know if you've managed to solve this yet, but my suggestion is to try OpenFOAM 2.2.x, or even 2.3.0 or 2.3.x. I say this because there were several bugs fixed in 2.2.x since 2.2.2 was released and I have a very vague recollection that this particular issue might have already been fixed... let me see if I can find the commit... OK... there are at least 5 to 10 commits that might be the solution for this problem, all released in 2.2.x after 2.2.2. Listing them all is a bit of a pain, so perhaps by date:
Best regards, Bruno PS: I only noticed this thread of yours, because of your second post here on the forum... and when I came to check your posts, I saw this interesting thread! |
Hi Bruno,
It still seemed very temperamental but I managed to get all of the simulations I needed in the end through perseverance! I was holding off changing the version of openFoam as I was halfway through my dissertation, but I will definitely upgrade now that I have all of the data I need and all my simulations are run. Thanks very much for the info! Kind regards, Andrew |
Hi All,
Sorry to revise this old thread, but I am facing a similar problem with OpenFOAM-v1812. I am meshing a very large problem, roughly ~1 billion cells, and every time snappyHexMesh seems to get stuck at the final balancing step. This is an example of the final lines of output before the code simply hangs for hours: Quote:
Thanks so much. |
Has anyone seen this issue? I just tried another job. It's running on 30 nodes, 2 processors per node, 128 GB RAM per node, with roughly 1 billion cells in the domain, and after about 6-8 hours snappyHexMesh successfully makes it through almost all of the castellation step, and then hangs at the "Doing final balancing" step for many hours. Again, I am using v1906.
Thanks |
Sorry, one more update. After quite a few hours, snappyHexMesh finally threw up this error message:
Quote:
Thanks. |
Quote:
|
Hi Bruno,
Thanks so much for taking the time to give me some ideas. Quick responses: 1. I am compiled for 64-bit labels. 2. It looks like "ptscotch" is not a valid decomposition method in v1906? At least I receive this error when decomposing: Quote:
If you have any other possible suggestions, they would be greatly appreciated. Could you also please explain what exactly this "doing final balancing" step actually does? I have maxLoadUnbalance set to 1, which means we shouldn't ever do any balancing, or at least that was my impression. Thanks again |
Quick answers:
Quote:
Quote:
Code:
scalar nIdealCells = If you believe that all processors were meant to have added new refinement cells, then what you can do is recompile the snappyHexMesh library, after making the following changes:
With this information, it's possible to assess if the issue that is happening is meant to happen or not. |
Hi Bruno,
Thanks again. I believe the final balancing step comes from here: Code:
if (!dryRun_ && Pstream:: parRun()) Could you please answer one quick question? If I manually subdivide my domain and run snappyHexMesh on the different subdomains, will the refined cells line up perfectly with the adjacent subdomains? Thanks again, I've been struggling with meshing this problem for several months and I'm running out of ideas. Best regards |
Quick answers:
Quote:
You're right, it doesn't care about the balance limit. So one alternative is that you edit the source code and comment out that block, so that it doesn't re-balance the mesh. Although this is something that should really be reported to the development team: https://develop.openfoam.com/Develop...M-plus/issues/ Quote:
But the trick should be to hack into the code and rebuild the library and move onward. It's a bit of a nasty hack, but at least you're able to mesh it. If it's a system-wide installation, you can copy the 2 main folders for snappyHexMesh and modify the 2 files inside "Make" accordingly to the usual workflow for custom code. |
Hi there,
I am running my case with about 2000 cores and I am also facing the same issue. Is rebuilding the library really the best way to avoid final balancing? I am working with a cluster and personally this is not the best way to approach this issue. Best regards, Ege |
All times are GMT -4. The time now is 10:36. |