[pattim]

Hello Everyone: I'm learning OF on a small infiniband cluster, and my reactingFoam runs are quite long - I was wondering if there's a way to use paraFoam to view intermediate fields during the run (to look for spatial convergence) or else an easy way to stop the run then restart the run if spatial convergence is not complete.


I'm using an ./Allrun script:

#!/bin/sh
cd "${0%/*}" || exit                                # Run from this directory
. ${WM_PROJECT_DIR:?}/bin/tools/RunFunctions        # Tutorial run functions
#------------------------------------------------------------------------------

# Application name
application=$(getApplication)

echo $application

rm -f 0/T
cp 0/T.orig 0/T

runApplication chemkinToFoam \
               chemkin/grimech30.dat chemkin/thermo30.dat chemkin/transportProperties \
               constant/reactionsGRI constant/thermo.compressibleGasGRI

runApplication blockMesh
runApplication setFields
runApplication decomposePar -force
runParallel $application
runApplication reconstructPar

Thank you very much!
Patricia

[HPE]

Hi,

- You may want to probe some field values in the field of interest as a function of time/iteration or monitoring residuals instead of visually assesing the convergence by looking at flow quantities, which would be a bit tedious, and misleading.
- Having said that, you can use sample and/or runTimePostProcessing utilities to output various cross-sections as VTK format, and visualise them while the case running.
- You can also execute paraFoam/ParaView on a running case as far as the time directories that you visualise are not deleted (e.g. by purgeWrite).

Hope these would give some indicators.

[pattim]

Thank you very much, HPE - This gives me some ideas to look at. It seemed to me this would be an easy thing to find with an interwebs search, but it turned out not.

I think it best (most comprehensive?) to be able to restart any run in the event that it didn't run long enough, but I haven't yet found how to do that for an arbitrary run. I probably don't know what term to use (in OF jargon) for a restart run, so searches aren't working yet.

Originally Posted by HPE

Hi,

- You may want to probe some field values in the field of interest as a function of time/iteration or monitoring residuals instead of visually assesing the convergence by looking at flow quantities, which would be a bit tedious, and misleading.
- Having said that, you can use sample and/or runTimePostProcessing utilities to output various cross-sections as VTK format, and visualise them while the case running.
- You can also execute paraFoam/ParaView on a running case as far as the time directories that you visualise are not deleted (e.g. by purgeWrite).

Hope these would give some indicators.

[HPE]

- Note also that you can view the decomposed fields in ParaView without reconstructing them by using OpenFOAM's reconstructPar or redistributePar, if that was the pain.

[pattim]

Originally Posted by HPE

- Note also that you can view the decomposed fields in ParaView without reconstructing them by using OpenFOAM's reconstructPar or redistributePar, if that was the pain.

Wow! Great! That worked really well. My runs take hours - but I just opened another terminal and ran reconstructPar, and then could use paraFoam to view the progress of the solution. I didn't realize that would work w/o interfering with runParallel. Excellent!! Thank you.

[HPE]

- Yes you can do that as well. But what I meant: you dont even need to execute reconstructPar. A parallel and running case can be visualised directly: Just before hit the 'Apply' button, one of the settings can be selected from the left panel. When I open my computer, I will try to upload a screenshot (writing via my phone now).

Good luck.

[Tobermory]

pattim - HPE means that on later versions of paraView there is an option to read directly from the decomposed data files instead of the reconstructed files. When you open up the case in paraview, and before you hit Apply to accept, check in the Properties pane on the left, above the Mesh Regions part and just below the Skip Zero Time check box. There may be some drop down menu options there, including "Case Type" at the top - if so, then change from the default "Reconstructed case" to "Decomposed Case".

Note, I don't have this feature on my old linux paraview 5.4 build, but it is there on my Win10 paraview 5.8.1 build, so it is likely to be a recent addition. i.e. you may need to update your paraview installation to use this feature.

[HPE]

Thank you very much Tobermory - and my apologies for writing in somewhat unclear manner - I usually write smt via my phone - that's why it happens.

Thank you!

[Tobermory]

No problem HPE - your post was clear and helpful, it's just that I only tripped across this option by mistake, recently, when I installed paraView on my Win10 PC ... I hadn't realised that I need to update my linux installation to catch up! It's possible that the OP may be in the same boat.

[pattim]

Thank you everyone - this is working very well for me. As an additional question - my computer crashed after working 12 hours on a solution (see first post for how I ran it). Is there a way to restart reactingFoam after a system crash or else when one must implement after safely halting with Alt-PrintScr-R-E-I-S-U-B?
Thank You!!

[Tobermory]

Yes - sure you can, providing that you wrote out some intermediate solutions. In your controlDict file, change the startFrom line to:

startFrom  latestTime;

and when you run again, it will start from the last save that you did (you may want to review your writeInterval setting in controlDict to see if it suits your purpose). You'll need to change your run script though ... I usually make a AllrunAgain script for this purpose. In your case it might look like the following:

#!/bin/sh
cd "${0%/*}" || exit                                # Run from this directory
. ${WM_PROJECT_DIR:?}/bin/tools/RunFunctions        # Tutorial run functions
#------------------------------------------------------------------------------

# Application name
application=$(getApplication)

echo $application

#  You should not need the following lines
#rm -f 0/T
#cp 0/T.orig 0/T

#runApplication chemkinToFoam \
               chemkin/grimech30.dat chemkin/thermo30.dat #chemkin/transportProperties \
               constant/reactionsGRI constant/thermo.compressibleGasGRI

#runApplication blockMesh
#runApplication setFields

#shouldd not need this either since the intermediate save will still be there in decomposed state
#runApplication decomposePar -force


#the -append flag adds to your previous run log, which is useful; else use a -overwrite flag
runParallel -append $application
runApplication -append reconstructPar

Good luck!

[pattim]

Thank you very much - that worked perfectly, even after halting reactingFoam with ctrl-C. Interestingly, "latestTime" seems to be a default now in controlDict. Since the time "0" is present often by default, that seems to work, so it wasn't necessary to modify controlDict.

Thanks!!
Patricia

Originally Posted by Tobermory

Yes - sure you can, providing that you wrote out some intermediate solutions. In your controlDict file, change the startFrom line to:

startFrom  latestTime;

and when you run again, it will start from the last save that you did (you may want to review your writeInterval setting in controlDict to see if it suits your purpose). You'll need to change your run script though ... I usually make a AllrunAgain script for this purpose. In your case it might look like the following:
<...>
Good luck!

[pattim]

Running reconstructPar followed by paraFoam works well, but I noticed some odd behavior. The U and T files don't always get reset to small text files in the "0" directory, even after issuing ./Allclean - they look like they contain binary information. I'm wondering if this is a 'bug' triggered by either viewing a non-reconstructPar'd solution or else something else I'm doing wrong (like not having all the cells add up to a mass fraction = 1.00)? It appears OF is run by a lot of scriptlets ("tools," etc.) and maybe one of these crashes while leaving the solver running just fine? (just guessing here!!)

Originally Posted by Tobermory

pattim - HPE means that on later versions of paraView there is an option to read directly from the decomposed data files instead of the reconstructed files. When you open up the case in paraview, and before you hit Apply to accept, check in the Properties pane on the left, above the Mesh Regions part and just below the Skip Zero Time check box. There may be some drop down menu options there, including "Case Type" at the top - if so, then change from the default "Reconstructed case" to "Decomposed Case".

Note, I don't have this feature on my old linux paraview 5.4 build, but it is there on my Win10 paraview 5.8.1 build, so it is likely to be a recent addition. i.e. you may need to update your paraview installation to use this feature.

[Tobermory]

Excellent - I am glad that worked for you. For the 0/ folder contents, remember I did comment out the lines

#rm -f 0/T
#cp 0/T.orig 0/T

in the adapted Allrun script that I suggested, so the 0 folder will remain as is, i.e. with the results of the earlier setFields operation. You should still have the 0.org folder though, with the slim ascii text files. If you want to reset back to a complete new start, you can always execute the above commands manually.

Agreed about the script files - getting your head around how to use those effectively can make your life a whole lot easier.

[pattim]

Originally Posted by Tobermory

Excellent - I am glad that worked for you. For the 0/ folder contents, remember I did comment out the lines

#rm -f 0/T
#cp 0/T.orig 0/T

in the adapted Allrun script that I suggested, so the 0 folder will remain as is, i.e. with the results of the earlier setFields operation. You should still have the 0.org folder though, with the slim ascii text files. If you want to reset back to a complete new start, you can always execute the above commands manually.

Agreed about the script files - getting your head around how to use those effectively can make your life a whole lot easier.

Thanks again - I think the problem I saw seeing is unrelated to paraFoam - some part of the solver was crashing. Some irregular BC was involved but the solver seemed to run OK.