[Tom Lauriks]

Hi Foamers,


I'm having problems in trying to avoid reconstructParMesh after running snappyHexMesh in parallel. I found another thread on this forum handling the exact same topic (Is it possible to avoid reconstructParMesh?, but the solution doesn't work for me.

The first thing that I do not understand about said solution, is that it is said to use the option -copyZero for decomposePar. However, when I try this, the boundaryField dicts in the 0 maps in the processor maps are not decomposed. When I use reconstructParMesh after using SHM and then decomposePar -force again, the boundaryField dicts are decomposed and then the solver doesn't error. In addition, I'm rather sure that I found in another thread, that copying the 0 from the not-decomposed case into the processor maps will not work, because it should be decomposed. (I know that in the motorBike tutorial, decomposePar -copyZero is used, but I do not understand why).

In addition, what I want to accomplish in the end, might complicate things a bit more. I'm using simpleFoam on OpenFOAM v6, to calculate the flow. I'm using the function object scalarTransport, to add scalar dispersion. I'm using scalarSemiImplicitSource, to provide a source term for the scalar in a part of my domain. I first refine the mesh around this part with refineMesh, in a cellSet created with topoSet. Then, I create another cellSet with topoSet, which will be used by scalarSemiImplicitSource.

To achieve the latter, the following has worked so far:
blockMesh
decomposePar
mpirun -np $cores snappyHexMesh -overwrite -parallel
reconstructParMesh
create mass source as described with refineMesh and topoSet
decomposePar -force
simpleFoam
Would it be possible to avoid the reconstructParMesh step in this workflow?

[LuckyTran]

Originally Posted by Tom Lauriks

The first thing that I do not understand about said solution, is that it is said to use the option -copyZero for decomposePar. However, when I try this, the boundaryField dicts in the 0 maps in the processor maps are not decomposed. When I use reconstructParMesh after using SHM and then decomposePar -force again, the boundaryField dicts are decomposed and then the solver doesn't error. In addition, I'm rather sure that I found in another thread, that copying the 0 from the not-decomposed case into the processor maps will not work, because it should be decomposed. (I know that in the motorBike tutorial, decomposePar -copyZero is used, but I do not understand why).

All of these are correct statements. Indeed -copyZero does not decompose the fields and they do need to be decomposed.


In the motorBike tutorial, it works because they're all uniform. That's why the option is limited to -copyZero and not -copyAnyTimeYouWant. It's there for speed purposes (so that you do not try to decompose a bunch of fields that don't need decomposing).


In order for you to skip having to reconstruct the mesh, you case would need to be like the motorBike tutorial and not need any mapping.

[Tom Lauriks]

Thanks! That answers all my questions.