CFD Online Logo CFD Online URL
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

multiRegion decomposePar should not decompose each region over all processors

Register Blogs Members List Search Today's Posts Mark Forums Read

LinkBack Thread Tools Search this Thread Display Modes
Old   May 22, 2016, 11:07
Default multiRegion decomposePar should not decompose each region over all processors
New Member
Join Date: May 2016
Posts: 1
Rep Power: 0
svenk is on a distinguished road
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?

Attached Images
File Type: png decompose1.png (3.6 KB, 481 views)
File Type: png decompose2.png (3.4 KB, 469 views)
svenk is offline   Reply With Quote

Old   April 11, 2018, 06:44
New Member
Hendrik Mayer
Join Date: Dec 2014
Posts: 2
Rep Power: 0
wiking69 is on a distinguished road
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,
wiking69 is offline   Reply With Quote


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
[mesh manipulation] Importing Multiple Meshes thomasnwalshiii OpenFOAM Meshing & Mesh Conversion 18 December 19, 2015 19:57
Unstabil Simulation with chtMultiRegionFoam mbay101 OpenFOAM Running, Solving & CFD 13 December 28, 2013 14:12
[Commercial meshers] Using starToFoam clo OpenFOAM Meshing & Mesh Conversion 33 September 26, 2012 05:04
[Other] StarToFoam error Kart OpenFOAM Meshing & Mesh Conversion 1 February 4, 2010 05:38
[Gmsh] Import gmsh msh to Foam adorean OpenFOAM Meshing & Mesh Conversion 24 April 27, 2005 09:19

All times are GMT -4. The time now is 06:18.