Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-21T09:05:28Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3005redistributePar -decompose and -reconstruct issue with collated I/O2023-12-21T09:05:28ZAliredistributePar -decompose and -reconstruct issue with collated I/O<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
(1) In general, it seems that the redistributePar -decompose does not distribute the sets (with or without collated IO).
(2) redistributePar -reconstruct when used with collated fileHandler does not reconstruct the lagrangian fields.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use the below commands to set up a case that has lagrangian fields and/or requires sets to be decomposed:
`runApplication blockMesh`
`runApplication topoSet`
`runParallel -s decompose redistributePar -decompose -fileHandler collated #-ioRanks '(0 2 4)'`
`mpirun -np 4 $(getApplication) -parallel -fileHandler collated #-ioRanks '(0 2 4)'`
`runParallel -s reconstruct redistributePar -reconstruct -fileHandler collated #-ioRanks '(0 2 4)'`
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
(1) Take simplifiedSiwek of lagrangian/coalChemistryFoam tutorial
(2) Use the above commands in Allrun-parallel in place of the original commands ---> You see the crash due to the absence of ignition sets in the decomposed mesh
(3) Comment the "source1" in constant/fvOptions to be able to run the case
(4) Set "the end"stopAt" to "writeNow" to run for 1 time step
(5) Re-execute the _modified_ "Allrun-parallel" script ---> You will see that the lagrangian fields have not been reconstructed.
I have attached the two scripts:
[Allrun-parallel](/uploads/7dc6891e3ecc1bc43f090d777c1e0740/Allrun-parallel)
[fvOptions](/uploads/434918f893468c19eb3a118ef18b9a2b/fvOptions)
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 2212, 2306
- Operating system :Linux
- Hardware info :
- Compiler :Gcc 10.5
### Possible fixes
Regarding the issue in reconstructing lagrangian fields, I think "findClouds" function in "parLagrangianDistributor" class searches in wrong paths i.e. old-style uncollated paths (processor0/ processor1/ ... etc) such that "cloudNames" object is empty. Unfortunately I do not know how to change the path to the collated style path i.e. processorsXX/
Regarding the decomposing of the sets issue, I have no idea!
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1415redistributePar : decompose mode - with region2024-01-16T05:55:20ZPrashant SonakarredistributePar : decompose mode - with region<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
redistributePar removes earlier decomposed (other) region.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any multi-region case operated in mode like:
mpirun -np 4 redistributePar -parallel -decompose -region A
mpirun -np 4 redistributePar -parallel -decompose -region B
The resulting decomposition contains only region B
### What is the expected *correct* behavior?
remove (overwrite) if the same region is decomposed, else, retain if any other region inside processor folders
### Relevant logs and/or images
Ref: EP#1055
@Mattijs @andy @markhttps://develop.openfoam.com/Development/openfoam/-/issues/624redistributePar -decompose with constraint2017-10-26T08:11:58ZvilfayeauredistributePar -decompose with constraintHallo,
redistributePar -decompose doesn't work with constraint (see log.redistributePar.cosntraint). I have run incompressible/pimpleDyMFoam/mixerVesselAMI2D with
singleProcessorFaceSets ((AMI -1));
without the constraint, it works (l...Hallo,
redistributePar -decompose doesn't work with constraint (see log.redistributePar.cosntraint). I have run incompressible/pimpleDyMFoam/mixerVesselAMI2D with
singleProcessorFaceSets ((AMI -1));
without the constraint, it works (log.redistributePar) and with decomposePar (log.decomposePAR) as well.
[log.redistributePar](/uploads/ad946e316e6163d61763f9efe35edf92/log.redistributePar)
[log.decomposePar](/uploads/685c9b10211d119170a0ad489a11222b/log.decomposePar)
[log.redistributePar.constraint](/uploads/bbd09943dce20616581eee277db9a92a/log.redistributePar.constraint)
Best,
Sebastienhttps://develop.openfoam.com/Development/openfoam/-/issues/2092redistributePar does not always detect whether reconstruction is needed2024-01-05T16:55:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not always detect whether reconstruction is needed### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh...### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh/*addressing)
- now redistributePar still thinks it has an undecomposed mesh (since above *addressing still exists)
### Target audience
Cleanup scripts that don't delete addressing
### Proposal
Add some more checks
(EP 1573) @Prashant @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1973redistributePar: does not decompose cyclicACMI2021-01-26T20:22:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar: does not decompose cyclicACMI<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`redistributePar -decompose` does not handle cyclicACMI
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run `redistributePar -decompose` on e.g.
`tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D`
It will give error about `turbulenceProperties` since it tries to evaluate the cyclicACMI (which evaluates the blockage bc)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/605redistributePar does not distribute clouds correctly2020-01-03T10:04:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not distribute clouds correctlyhttps://develop.openfoam.com/Development/openfoam/-/issues/1953redistributePar does not work in -decompose mode anymore2021-03-15T11:37:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not work in -decompose mode anymore<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
redistributePar -decompose hangs upon reading system/controlDict
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case:
```redistributePar -decompose```
### What is the current *bug* behaviour?
<!-- What actually happens -->
Hangs in fileHandler in cacheProcessor directories.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : develop since (I assume) 627d79dba68d9436a8ce3e4df5e92f40d976cfed
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/806redistributePar does not work with collated I/O format2022-05-07T08:43:37ZAdminredistributePar does not work with collated I/O formatHi, it seems that the redistributePar Tool is only written for uncollated format. Using collated format is not possible. Process stucks - see logfile. For reproducing I run the cavitiy mesh/parallel case
controlDict adds:
OptimisationS...Hi, it seems that the redistributePar Tool is only written for uncollated format. Using collated format is not possible. Process stucks - see logfile. For reproducing I run the cavitiy mesh/parallel case
controlDict adds:
OptimisationSwitches
{
//- Parallel IO file handler
// collated (default), collated or masterUncollated
fileHandler collated;
maxThreadFileBufferSize 0; -> this is set to zero by purpose for cluster setup!
maxMasterFileBufferSize 2e9;
}
[log.redistributePar.decompose](/uploads/9226895799c39911aa7529d4754ed860/log.redistributePar.decompose)
\#\# Reattaching the author to the issue ticket: @hxaxtma \#\#Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1450redistributePar + dyM + lagrangian leads to creash2019-10-25T11:46:06ZAdminredistributePar + dyM + lagrangian leads to creash### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads...### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads to a crash at the very first time step after redistribution.
### Steps to reproduce
Start any lagrangian solver with dynamic Mesh in parallel. Stop at first write out. Use redistributePar in parallel, restart the solver at latest timestep.
### Example case
This bug can easily be reproduced using `sprayDyMFoam` in combination with the aachenBomb tutorial case. I attached [aachenBomb.zip](/uploads/8c10285231317d5a4f48247de25fb9de/aachenBomb.zip) tutorial with minimal changes to include dynamic mesh. Just run the Allrun script.
### What is the current *bug* behaviour?
The solver crashes at first time step after executing redistributePar
### What is the expected *correct* behavior?
The solver should run.
### Relevant logs and/or images
The error message looks as following:
`
[3] [2] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
[3] #1 Foam::sigSegv::sigHandler(int)[2] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #2 ? at ??:?
[2] #2 ? in /usr/lib64/libc.so.6
in /usr/lib64/libc.so.6
[3] #3 [2] #3 Foam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) constFoam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) const at ??:?
[3] #4 at ??:?
[2] #4 Foam::particle::position() constFoam::particle::position() const at ??:?
[3] #5 at ??:?
[2] #5 ?? at ??:?
[2] #6 at ??:?
[3] #6 ?? at ??:?
[3] #7 __libc_start_main at ??:?
[2] #7 __libc_start_main in /usr/lib64/libc.so.6
[3] #8 in /usr/lib64/libc.so.6
[2] #8 ?? at ??:?
[tauruslogin3:22317:0] Caught signal 11 (Segmentation fault)
at ??:?
[tauruslogin3:22316:0] Caught signal 11 (Segmentation fault)
`
### Environment information
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info : Intel CPU, openmpi
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1118redistributePar error when reducing the number of processors2018-12-12T21:16:10ZAdminredistributePar error when reducing the number of processorsHi,
I'm facing the next issue with `redistributePar`. It fails for me when trying to redistribute from a higher number of processors to a smaller one.
# Steps to reproduce it
For example, modifying the `$FOAM_TUTORIALS/mesh/parallel/c...Hi,
I'm facing the next issue with `redistributePar`. It fails for me when trying to redistribute from a higher number of processors to a smaller one.
# Steps to reproduce it
For example, modifying the `$FOAM_TUTORIALS/mesh/parallel/cavity` tutorial to run the first steps with 5 processors and redistributing to 2 rather than vice versa.
[cavity5To2.zip](/uploads/2f24a867c36cd4cb68dbf1c978b38aac/cavity5To2.zip)
# Error log
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1806 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1806
Arch : "LSB;label=32;scalar=64"
Exec : redistributePar -parallel -decomposeParDict system/decomposeParDict-2 -cellDist
Date : Dec 11 2018
Time : 19:12:26
Host : "e06709f01e3c"
PID : 797
I/O : uncollated
Case : /home/ofuser/workingDir/OpenFOAM/ofuser-v1806/run/cavity
nProcs : 2
Hosts :
(
(e06709f01e3c 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
--> FOAM Warning :
From function int main(int, char**)
in file redistributePar.C at line 2300
Detected floating point exception trapping (FOAM_SIGFPE). This might give
problems when mapping fields. Switch it off in case of problems.
Creating time directories on all processors
Create time
Create undecomposed database
Using mesh subdirectory "polyMesh"
Setting time to that of master or undecomposed case : 0.5
Checking for mesh in "/home/ofuser/workingDir/OpenFOAM/ofuser-v1806/run/cavity/processor0/constant/polyMesh/faces"
Per processor mesh availability:
2{1}
[1] #0 Foam::error::printStack(Foam::Ostream&)[e06709f01e3c:00797] *** Process received signal ***
[e06709f01e3c:00797] Signal: Aborted (6)
[e06709f01e3c:00797] Signal code: (-6)
[e06709f01e3c:00797] [ 0] /lib64/libc.so.6(+0x35270)[0x7f4a16ea1270]
[e06709f01e3c:00797] [ 1] /lib64/libc.so.6(gsignal+0x37)[0x7f4a16ea11f7]
[e06709f01e3c:00797] [ 2] /lib64/libc.so.6(abort+0x148)[0x7f4a16ea28e8]
[e06709f01e3c:00797] [ 3] /lib64/libc.so.6(+0x74f47)[0x7f4a16ee0f47]
[e06709f01e3c:00797] [ 4] /lib64/libc.so.6(+0x7ab54)[0x7f4a16ee6b54]
[e06709f01e3c:00797] [ 5] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam4ListIcE7setSizeEi+0x1f5)[0x7f4a1805c155]
[e06709f01e3c:00797] [ 6] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam9UOPstream5writeEi+0xb0)[0x7f4a18069810]
[e06709f01e3c:00797] [ 7] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4FoamlsERNS_7OstreamEi+0xa)[0x7f4a17fd1a1a]
[e06709f01e3c:00797] [ 8] redistributePar(_ZNK4Foam5UListIiE9writeListERNS_7OstreamEi+0xc8)[0x44ca78]
[e06709f01e3c:00797] [ 9] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18processorPolyPatch14initUpdateMeshERNS_14PstreamBuffersE+0x292)[0x7f4a18202e22]
[e06709f01e3c:00797] [10] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam16polyBoundaryMesh10updateMeshEv+0x275)[0x7f4a1820b635]
[e06709f01e3c:00797] [11] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam8polyMeshC1ERKNS_8IOobjectE+0xbf6)[0x7f4a1825b346]
[e06709f01e3c:00797] [12] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam6fvMeshC2ERKNS_8IOobjectE+0x19)[0x7f4a1b4da8b9]
[e06709f01e3c:00797] [13] redistributePar[0x465014]
[e06709f01e3c:00797] [14] redistributePar[0x44838f]
[e06709f01e3c:00797] [15] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4a16e8dc05]
[e06709f01e3c:00797] [16] redistributePar[0x44b410]
[e06709f01e3c:00797] *** End of error message ***
at ??:?
[1] #1 Foam::sigSegv::sigHandler(int)--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 797 on node e06709f01e3c exited on signal 6 (Aborted).
--------------------------------------------------------------------------
```Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/5redistributePar fails2023-08-19T21:13:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar failsmpirun -np 4 redistributePar -parallel -reconstruct -time 7
- undecomposed mesh is starting blockMesh
- mesh generated in parallel
- time 7 is the mesh at some step in snappyHexMesh
```
Time = 7
Reading undecomposed mesh (on ...mpirun -np 4 redistributePar -parallel -reconstruct -time 7
- undecomposed mesh is starting blockMesh
- mesh generated in parallel
- time 7 is the mesh at some step in snappyHexMesh
```
Time = 7
Reading undecomposed mesh (on master)
Reading local, decomposed mesh
Boundary definition OK.
Reading addressing from procXXXAddressing at "7"
[1] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[1] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
[3] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
[2] #1 Foam::sigSegv::sigHandler(int, siginfo_t*, void*) at ??:?
```Functionality migration from internal development linehttps://develop.openfoam.com/Development/openfoam/-/issues/679redistributePar fails for faMesh2020-01-07T16:32:23ZMark OLESENredistributePar fails for faMeshv1806Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2574redistributePar fails with area fields when there are no edge boundaries2022-09-07T14:33:08ZMark OLESENredistributePar fails with area fields when there are no edge boundariesOdd failure reported on EP1371 (item 4) - caused by a programming oversight in redistributePar.
As the image below shows, it is quite possible to have a fully enclosed finiteArea patch without any physical boundary edges (only processor ...Odd failure reported on EP1371 (item 4) - caused by a programming oversight in redistributePar.
As the image below shows, it is quite possible to have a fully enclosed finiteArea patch without any physical boundary edges (only processor ones).
![Plates_p1](/uploads/56eb1879bad523afdf58fe58c1bdbbff/Plates_p1.png)
@kutiMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/656redistributePar leaves old files around2021-07-06T11:28:38ZMark OLESENredistributePar leaves old files aroundAfter redistribution, the cellProcAddressing etc files are left behind from the previous decomposition. This are incorrect (and potentially troublesome).
- option 1: remove the offending files
- option 2: redistribute the addressing to ...After redistribution, the cellProcAddressing etc files are left behind from the previous decomposition. This are incorrect (and potentially troublesome).
- option 1: remove the offending files
- option 2: redistribute the addressing to reflect the new distribution.
Comment: the addressing would only be used by reconstructPar. But if redistributePar has already been used to redistribute, then it make sense to use `redistributePar -reconstruct` for reconstruction as well.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2120redistributePar messes up zones2021-07-29T13:58:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar messes up zones<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
redistributePar produces different zones (e.g. faceZones, cellZones) if the zones are not in alphabetical order
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`Allrun` in attached case. Input has 0 faces in faceZone 'innerFz', after redistributePar it has 8 faces.
[redistributePar-issue.tgz](/uploads/cc64ed8fba1346d8a4a4c3552fe34ead/redistributePar-issue.tgz)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
### Possible fixes
Somewhere in fvMeshDistribute.C it can change the order of the zones. This might not be done consistently?
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
@Prashant @markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2466redistributePar -reconstruct -constant fails2022-05-12T10:41:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct -constant fails<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`redistributePar -reconstruct -constant` fails with NO_READ specified.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
e.g. in cavity:
```
blockMesh
decomposePar (with e.g. hierarchical (2 1 1))
rm -r constant/polyMesh
mpirun -np 2 redistributePar -reconstruct -constant -parallel
```
### Example case
Any e.g. cavity tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Error message with `NO_READ` on constructor
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Add 0 size?
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/120redistributePar utility does not write pointDisplacement field2024-01-10T17:09:51ZPawan GhildiyalredistributePar utility does not write pointDisplacement fieldredistributePar utility when used to decompose , does not write pointDisplacement field .
testcase : tutorials/multiphase/interDyMFoam/ras/DTCHullredistributePar utility when used to decompose , does not write pointDisplacement field .
testcase : tutorials/multiphase/interDyMFoam/ras/DTCHullMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/642redistributePar with -decompose and ptscotch crashes2020-01-03T11:21:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar with -decompose and ptscotch crashesptscotch returns a one element decomposition on domains with zero cells.ptscotch returns a one element decomposition on domains with zero cells.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/924redistributePar with numberOfSubdomains 1 in decomposeParDict2020-01-08T14:38:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar with numberOfSubdomains 1 in decomposeParDictRunning cht cases with in decomposeParDict:
```
regions
{
heater
{
numberOfSubdomains 1;
}
}
```
conflicts with the old way of doing reconstruction through this method. In earlier versions of redistributePar we used ...Running cht cases with in decomposeParDict:
```
regions
{
heater
{
numberOfSubdomains 1;
}
}
```
conflicts with the old way of doing reconstruction through this method. In earlier versions of redistributePar we used `numberOfSubdomains = 1` to indicate reconstruction mode. Now there is a `-reconstruct` option.
Choices:
- recognise multi-region cases and don't switch on reconstruction mode if numberOfSubdomains 1
- do not use numberOfSubdomains setting to indicate reconstruction mode
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/184Reduce code duplication for coded boundary conditions2016-12-23T12:44:52ZMark OLESENReduce code duplication for coded boundary conditionsVersion v1612Mark OLESENMark OLESEN