[yek_irani]

Hello,

I am performing a simulation with the pimpleFoam solver using OpenFOAM v1912. The calculation is running on several processors. I am wondering what is the best practice for a smooth restart. In system/controlDict I am writing out data in binary format, and the variable startFrom is set to “latestTime”.

My main question is whether it makes a difference if I:

1) reconstruct the data from all "processor" subfolders using reconstructPar, delete the aforementioned data subfolders and then rerun the decomposePar, renumberMesh followed by pimpleFoam. This approach is recommended in this post

OR,

2) leave the data decomposed in the separate processor subfolders and imply invoke pimpleFoam.

Option #2 seems like less work to me.

Thank you for your thoughts.

[HPE]

Could you explain further what `smooth` restart is?

Otherwise, the second option will be enough to restart whatever computation you have.

[yek_irani]

Thank you HPE for your (hopefully "herpes free") response.
"Smooth" to me means minimizing the extent of initial transient blips in the solution achieved thus far.

[Swift]

Hi,


I agree with HPE and would resume from the previously decomposed state just because it is less work. I haven't verified this, but I don't think that it should make any difference if you resume from a decomposed state or decompose a time step and then resume.


The decomposed result and the reconstructed result both contain the same information, it should not make any difference to how the solution proceeds.



Are you seeing strange results when you resume a solution? Can you plot the residuals?



Regards,
Thomas

[yek_irani]

Hello,

Thank you for your response. I haven't compared the two options. My primary intention was to get feedback on what experienced users felt was 'best practice'.

Cheers.

[Ship Designer]

Hi all,

this is not strictly an answer to the original question, but might sitlll be useful.

I've experienced fatal errors after restarting interrupted decomposed cases solved by interFoam. I don't remember the exact error message right now. To correct the problem, I deleted all field files other than those located in "0" from each processor folder, e.g. alphaPhi0.water, phi. After that, interFoam restarted the solution at the latest time without complaints. After restarting the solution, the residuals are not the same as prior to the interuption, but seem to recover after a few time steps.

[yek_irani]

Hi Claudio,

How was the job interrupted? I try to use the stopAtWriteNowSignal variable to ensure the time step completes before stopping, as per the description here:
https://openfoam.org/release/2-1-0/r...-write-timing/

Being a bit of a beginner to OpenFOAM, I am somewhat puzzled by the approach or workaround you employed. If you "deleted all field files other than those located in "0" from each processor folder", what solution are you left with to restart from? Did you reconstruct the data before deleting?

[Ship Designer]

Hello Maziar,


I believe in those instances I aborted the calculations manually for some reason. I admit that's probably not the best way to do it. Maybe I should make sure that interFoam ends naturally, like setting endTime to the next ordinary write and let it write all the files properly, like you suggest. Thanks.



By deleting those field files I did, interFoam will restart and continue the solution based on the same files which are initially contained in the 0 directory, i.e. U, p_rgh, alpha.water and any turbulence model fields, but with the values of the solution so far. I'm sure it's not the best way to do it, but given the fatal error I got, it was the only way I found to continue solution without having to waste hours and start over again. It's just a solution to a unique problem you're unlikely to encounter. I apologize if this was off-topic and caused confusion. Nevermind.



Cheers

[ndhar]

I was asked to do the same with the latest time step of the simulation which I think I have been able to do (fingers crossed), being a new OpenFOAM user it was hard for me to figure that out.

[cckohrs]

When I tried to restart buoyantReactingFoam I got errors that the processor#/0/p etc. are missing. So the following commands works for successful restart of a buoyantReactingFoam cases:

decomposePar -latestTime -time 0 -force
mpirun -np 7 buoyantReactingFoam -parallel
reconstructPar

Change 7 and possibly the solver to suit your case. I also add the following to clean up the processor folders.
rm -rf processor*