[Rojj]

Hi,

I am trying to use redistributePar to change the number of processors after snappyHexMesh.

I am using OF6.0 (www.openfoam.org) on ubuntu 18.04.

I have meshed my case with

mpirun -np NP snappyHexMesh -overwrite -parallel

At this point i have my NP processor folders all with 0 and constant subfolders.

I then update decomposeParDict with the new number of processors (NNP) - I am using scotch.

I finally run

mpirun -np NNP redistributePar -constant -overwrite -parallel

There are no errors and the new processor folders are created with the constant subfolder but without the 0 folder.

I then try to run simpleFoam with

mpirun -np NNP simpleFoam -parallel

but I receive the error 'cannot find patchfield' in the new processor folders as I expected.

I have also tried using renumberMesh

mpirun -np NNP renumberMesh -overwrite -parallel

This gives the same error as simpleFoam

Finally I tried to copy the original 0 folder to the various processors and run renumberMesh again (I knew it was wrong, but I didn't know what else to try!) and of course I had an error about inconsistent number of cells.

Any idea on how to use redistributePar correctly?

I have searched the forum and it seems the changeDictionary could be one possible solution. I tried, but I could not figure it out how to use it.

Thanks!

[Swift]

Hi Ruggiero,

What happens if you reconstruct the mesh after snappyHexMesh with

reconstructParMesh -constant

?

Then edit your decomposeParDict file for the new number of processors and then run:

decomposePar -force

Does that create the processor folders with 0 folders within them? This is the workflow that I use.

Regards,
Thomas

[Rojj]

Hi Thomas,

That is the typical workflow I use as well and it works fine (except that I do not need to use the -force option).

However I would like to avoid running reconstructParMesh and reconstructPar.

Unfortunately I cannot guarantee that the number of cores used for meshing is the same used for running the case. This is why I started to look into redistributePar.

Cheers

[Swift]

Hi Ruggiero,

When you decompose your mesh before running snappyHexMesh, try running decomposePar with the copyZero flag, so:

decomposePar -copyZero
mpirun np NP snappyHexMesh -overwrite -parallel

and then run the commands as you had them listed.


Regards,
Thomas

[Rojj]

Hi Thomas,

unfortunately I get the same problem: 0 folders are not copied to the new processors.

It seems that the option -copyZero is missing from redistributePar?

Interestingly if I use just decomposePar I get

.....
.....
Number of processor faces = 506
Max number of cells = 8800 (0% above average 8800)
Max number of processor patches = 1 (0% above average 1)
Max number of faces between processors = 506 (0% above average 506)

Time = 0

Processor 0: field transfer
Processor 1: field transfer

End

But if I use decomposePar -copyZero I get

Number of processor faces = 506
Max number of cells = 8800 (0% above average 8800)
Max number of processor patches = 1 (0% above average 1)
Max number of faces between processors = 506 (0% above average 506)

Processor 0: copying "/home/ubuntu/OpenFOAM/ubuntu-6/run/redistribute_New-Area_Baseline/N/0"
 to "/home/ubuntu/OpenFOAM/ubuntu-6/run/redistribute_New-Area_Baseline/N/processor0/0"
Processor 1: copying "/home/ubuntu/OpenFOAM/ubuntu-6/run/redistribute_New-Area_Baseline/N/0"
 to "/home/ubuntu/OpenFOAM/ubuntu-6/run/redistribute_New-Area_Baseline/N/processor1/0"

End

So it looks like it is doing something different, but still the 0 folders are not copied across

[vince_cfd]

Hello Rojj,

I have a similar problem: the 0 folder isn't copied when using decomposePar. For now I have just copied the important files (like U, p, T, epsilon ...) to the respective place for the 0 and the constant folder. I got the computation to work this way, but I still think it is weird to have to copy all of that by hand.

Have you been able to solve your problem?

Greetings

[Rojj]

Hello Vincent,

I actually abandoned that test. I will definitely try your approach. I do everything programmatically so it should be quite easy to implement.

I will let you know how it goes. It will take a while though as I am quite busy with other tasks.

Cheers
Ruggiero

[simrego]

Hi!


What happens if you leave the -constant switch? I have used it many times without any problems. And I don't remember if the -constant was needed.

[otaolafr]

Originally Posted by Rojj

Hello Vincent,

I actually abandoned that test. I will definitely try your approach. I do everything programmatically so it should be quite easy to implement.

I will let you know how it goes. It will take a while though as I am quite busy with other tasks.

Cheers
Ruggiero

hi rojj,
did you find a work around this? in the OF esi vr there is

restore0Dir -processor

but not the case in the foundation vr, and as you i am using it (well the V.7 actually...). either way, did you solve it?
also i assume that

mpirun -np NP ***** -parallel

gives the same result as:

runParallel *****

,no? sorry i am still learning this software, and it is noooot an easy task ahahah.
hope to know if you find a solution.
best regards

[HPE]

Hi,

- "runParallel Y" is a bash script with which "mpirun -np X Y -parallel >& log.Y" is computed, where "X" the number of processors defined in "decomposeParDict" and "Y" is the OpenFOAM application which should be parallel executable.

[shahabgol]

Hi,
The main reason is that your simulation does not start from time 0.
Correct this in your controlDict and 0 folders will appear on all the processors when you perform decomposePar

[fran.cesc]

I had the same problem.

The issue for me was that my 0 folder missed one of the required input files for the specific solver detailed in controlDict. I added the missing file in 0 and then decomposePar worked fine.