[Antimony]

Hi All,

I have been thinking of a better way to run snappyHexMesh from my current approach. Here is what I typically do:

Run blockMesh, then run decomposePar (usually with the scotch method [I understand that it does load balancing when decomposing the mesh]) and then run snappyHexMesh in parallel.

Let us say that the problem that I am solving is an external flow, and the geometry (STL files) is at the center of the domain. The entire domain has been blockMeshed and decomposed.

Now, by running snappyHexMesh in parallel, I am sure that the processors that have the geometry within their bounds are going to be worked far more than the ones on the outside (via local refinements), resulting in unequal processor loading.

And yet, the processor distribution was determined based on the blockMesh.

Is there any way by which I could get decomposePar to look at the geometry files and then make an educated guess as to where more cells are likely and decompose the mesh accordingly?

I noticed that the scotch method has coefficients and strategy options as well. Would any of those help?

One solution that I can think of is to run snappyHexMesh with just the castellated option at true and then decompose that case and rerun snappy in parallel with the snap option at true. However, I am not sure that is a good idea either, as I want to speed up the entire snappyHexMesh process in parallel and not just a part of it.

Has anyone encountered a similar problem before? (Quick search didn't yield anything).

Any comments/suggestions are most welcome!

Cheers,
Antimony

[Antimony]

Hi All,

Basically, one does not need to worry about what I had mentioned in my previous post, because snappyHexMesh does load balancing by itself when run in parallel.

This is mentioned here: http://www.openfoam.com/documentatio...ppyHexMesh.php (It runs in parallel with a load balancing step every iteration being the crucial line)

So essentially, the base decomposition using decomposePar that needs to be run, is simply used as a first step by snappy, before it changes the partitioning of the mesh.

For those that are interested, here are a couple of snapshots of the partitioning before and after snapping (Simple case with a bunch of cubes in a bigger cube with 2 processors)

Hope this helps someone else in the future.

Cheers,
Antimony