OpenFOAM v11 User Guide - 7.2 Post-processing command line interface (CLI)

7.2 Post-processing command line interface (CLI)

Post-processing is provided directly within OpenFOAM through the command line including data processing, sampling (e.g. probes, graph plotting) visualisation, case control and run-time I/O. Functionality can be executed by:

• conventional post-processing, a data processing activity that occurs after a simulation has run;
• run-time processing, data processing that is performed during the running of a simulation.

Both approaches have advantages. Conventional post-processing allows the user to choose how to analyse data after the results are obtained. Run-time processing offers greater flexibility because it has access to all the data in the database of the run at all times, rather than just the data written during the simulation. It also allows the user to monitor processed data during a simulation and provides a greater level of convenience because the processed results can be available immediately to the user when the simulation ends.

There are 3 methods of post-processing that cover the options described above.

• The case can be configured to include run-time processing during the simulation.
• The foamPostProcess utility provides conventional post-processing of data after a simulation is completed.
• The foamPostProcessutility is run with a -solver which provides additional access to data available on the database for the particular solver.

All modes of post-processing access the same functionality implemented in OpenFOAM in the function object framework. Function objects can be listed using foamToC by the following command.

The list represents the underlying post-processing functionality. Almost all the functionality is packaged into a set of configured tools that are conveniently integrated within the post-processing CLI. Those tools are located in $FOAM_ETC/caseDicts/postProcessing and are listed by running foamPostProcesswith the -list option. This produces a list of tools catalogued in section 7.3 .

7.2.1 Run-time data processing

When a user wishes to process data during a simulation, they need to configure the case accordingly. The configuration process is as follows, using an example of monitoring flow rate at an outlet patch named outlet.

Firstly, the user should include the patchFlowRate function in functions sub-dictionary in the case controlDict file, using the #includeFunc directive.

That will include the functionality in the patchFlowRate configuration file, located in the directory hierarchy beginning with $FOAM_ETC/caseDicts/postProcessing.

The configuration of patchFlowRate requires the name of the patch to be supplied. Option 1 for doing this is that the user copies the patchFlowRate file into their case system directory. The foamGet script copies the file conveniently, e.g. 

The patch name can be edited in the copied file to be outlet. When the solver is run, it will pick up an included function in the local case system directory, in precedence over $FOAM_ETC/caseDicts/postProcessing. The flow rate through the patch will be calculated and written out into a file within a directory named postProcessing.

Option 2 for specifying the patch name is to provide the name as an argument to the patchFlowRate in the #includeFunc directive, using the syntax keyword=entry.

In the case where the keyword is field or fields, only the entry is needed when specifying an argument to a function. For example, if the user wanted to calculate and write out the magnitude of velocity into time directories during a simulation they could simply add the following to the functions sub-dictionary in controlDict.

This works because the function’s argument U is represented by the keyword field, see $FOAM_ETC/caseDicts/postProcessing/fields/mag.

Some functions require the setting of many parameters, e.g. to calculate forces and generate elements for visualisation, etc. For those functions, it is more reliable and convenient to copy and configure the function using option 1 (above) rather than through arguments.

7.2.2 The foamPostProcess utility

The user can execute post-processing functions after the simulation is complete using the foamPostProcess utility. We can us illustrate the use of foamPostProcessusing the pitzDailySteady case from section 2.1 . The tutorial does not need to be run to use the case, it can instead be copied into the user’s run directory and run using its accompanying Allrun script as follows.

Now the user can run execute post-processing functions with foamPostProcess. The -help option provides a summary of its use. Simple functions like mag can be executed using the -func option; text on the command line generally needs to be quoted ("…") if it contains punctuation characters. This operation calculates and writes the field of magnitude of velocity into a file named mag(U) in each time directory. Similarly, the patchFlowRate example can be executed using foamPostProcess. Let us say the user now wants to calculate total pressure for incompressible flow with kinematic pressure, . The function is available, named totalPressureIncompressible, which requires a rhoInf parameter to be specified. The user could attempt first to run as follows. This returns the following error message. The error message is telling the user that the velocity field U is not loaded. For the function to work, both the field needs to be loaded using the -field option as follows.

A more complex example is calculating wall shear stress using the wallShearStress function.

Even loading relevant fields, the post-processing fails with the following message. The message is telling us that the foamPostProcessutility has not constructed the necessary models, i.e. a turbulence model, that the incompressibleFluid solver module used when running the simulation. This is a situation where we need to post-process (as opposed to run-time process) using the -solver option modelling will be available that the post-processing function needs. Note that no fields need to be supplied, e.g. using ”-field U”, because incompressibleFluid module constructs and stores the required fields. Functions can also be selected by the #includeFunc directive in functions in the controlDict file, instead of the -func option.