|May 22, 2016, 10:07||
multiRegion decomposePar should not decompose each region over all processors
Join Date: May 2016
Posts: 1Rep Power: 0
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?
|Thread||Thread Starter||Forum||Replies||Last Post|
|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|
|Using starToFoam||clo||OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ...||33||September 26, 2012 04:04|
|StarToFoam error||Kart||OpenFOAM Meshing & Mesh Conversion||1||February 4, 2010 05:38|
|Import gmsh msh to Foam||adorean||Open Source Meshers: Gmsh, Netgen, CGNS, ...||24||April 27, 2005 08:19|