[svenk]

Hello,
I am currently studying efficient parallel decompositions of multi-region cases.
If I look at $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/multiRegionHeater and similar examples, I find that each of the solid regions (heater, left/rightSolid) and each of the fluid regions (bottom/topAir) has its own decomposeParDict. In the tutorial those decomposeParDicts split each region into four processor zones, so that in the end each processor computes a fragment from each region. The consequence is that each processor has a much larger interface to other processors than necessary.

The situation is like this, where the lines depict the region boundaries and the numbers show which zone of each region is assigned to which processor:



Doesn't it make more sense to assign the first region to the first n1 processors, the second region to the next n2 processors etc.:



Is it possible to tell the decomposeParDict of each region r that it should assign the parts not to all available processors, but only to #m ... #n, where m and n change from region to region?

Thanks
Sven

[wiking69]

Hello Sven,
Hello everyone else,

the decomposition implemented in OpenFOAM actually makes sense, at least for chtMultiregionSimpleFoam.

In this solver, the regions are solved sequentially.
So it is true, that each processor has a bit of every region. But as the solver starts to solve the first region, the processors work together as well as in a single-region case.

As long as you don't write a solver that solves all regions simultaneously, the current implementation is fine.

I hope I could help.
Best regards,
Hendrik