OpenFOAM® v1606+: Post-processing

30/06/2016

Noise FFT analysis

The noise modelling capabilities in OPENFOAM® have been significantly refactored and extended, offering:

  • new run-time selectable noise models
  • new run-time selectable windowing methods
  • new FFT algorithm

Results are output as functions of frequency, including

  • Power Spectral Density (PSD) in PaPa/Hz and dB/Hz,
  • Sound Pressure Level (SPL) in Pa and dB, and
  • 1/3 octave PSD and SPL, whereby the bins are constrained to pass through the centre frequency at 1  \relax \special {t4ht= kHz.

Run-time selectable noise models comprise

  • point noise
  • surface noise

The point noise model offers similar graph-based output to previous OPENFOAM® versions.

The parallel-aware surface noise model computes the output values per face, output as surface data. This relies on a surface format that supports multiple instances, e.g. time, which is currently limited to using the Ensight file format. Each output surface represents the response at a given frequency. In addition, graphs are produced to show the surface averaged PSD and SPL as functions of frequency.

Data windowing functionality is now run-time selectable, offering

  • Hanning, with options including symmetry, and extended (non-zero at the end-points)
  • uniform,
  • overlapping windows

The following series of images show results from an assessment of the rider’s helmet from the motorBike tutorial. The PSD at 793 Hz is shown below.

[Picture]

Surface average PSD as a function of frequency:

[Picture]

Surface average 1/3 octave SPL as a function of frequency:

[Picture]

The underlying FFT algorithm has been replaced by the well-adopted FFTW library.Note that this introduces an additional dependency that can be met via either a system-wide or ThirdParty installation.

Reaction sensitivity

The new reactionSensitivityAnalysis function object indicates the reaction rates of creation or destruction of species in each reaction for chemistry solvers.

It is specified using in the controlDict using:

functions
{
    sensitivityAnalysis
    {
        functionObjectLibs  ("libutilityFunctionObjects.so");
        type                psiReactionsSensitivityAnalysis;
        outputControl       outputTime;
        enabled             true;
    }
}
The output comprises four data files:
  • consumption.dat: consumption rate
  • production.dat: destruction rate
  • productionInt.dat: integral between dumps of the production rate
  • consumptionInt.dat: integral between dumps of the consumption rate

The output format e.g. for the consumption.dat file takes the form:

time :      1e-2
delta T:   1e-5
Reaction                 specie1    specie2
1                          RR11       RR12
2                          RR21       RR22
....

time : 2e-2
delta T: 1e-5
Reaction                 specie1    specie2
1                          RR11       RR12
2                          RR21       RR22
....
The following plot shows the production rate of a reduced number of species from the GRI mechanism, for each reaction in the system.

[Picture]

Example
GRI: $FOAM_TUTORIALS/combustion/chemFoam/gri

Source code
$FOAM_SRC/postProcessing/functionObjects/utilities/reactionSensitivityAnalysis

Profiling

A new profiling tool has been implemented to report the time taken to accomplish certain tasks, how often they were called, and their associated memory information. The default instrumentation includes profiling of function objects, writing the object registry, matrix solution, and Lagrangian cloud evolution.

Profiling is available for all solvers and for snappyHexMesh. To minimize the impact of profiling on parallel cases, it remains separate for each parallel process, avoiding the need for additional parallel reductions. To enable profiling with the default settings, users should add the following entry to the the system/controlDict dictionary:

profiling
{}
Which corresponds to the longer form:

profiling
{
    active      true;
    cpuInfo     true;
    memInfo     false;
    sysInfo     true;
}
The output is written under the time directories in the <time>/uniform/profiling file.

Sample output:

profiling
{
    trigger31
    {
        id              31;
        parentId        0;
        description     "objectRegistry::writeObject";
        calls           6;
        totalTime       9.833197;
        childTime       0;
        onStack         true;
    }
    ...
    trigger6
    {
        id              6;
        parentId        0;
        description     "fvMatrix::solve.U";
        calls           60;
        totalTime       2.483518;
        childTime       1.945374;
        onStack         false;
    }
    trigger7
    {
        id              7;
        parentId        6;
        description     "lduMatrix::solver.Ux";
        calls           60;
        totalTime       0.599489;
        childTime       0.384732;
        onStack         false;
    }
    ...
    trigger30
    {
        id              30;
        parentId        0;
        description     "cloud::solve";
        calls           6;
        totalTime       6.615408;
        childTime       0;
        onStack         false;
    }
}
In snappyHexMesh, profiling was added to help detecting memory surges. To enable this feature, either adapt the system/controlDict as follows:

profiling
{
    memInfo         true;
}
or, more conveniently, simply specify the -profiling option when running snappyHexMesh.

Example
Channel: $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/verticalChannelLTS

Future plans
Profiling capabilities will be added in the future to other utilities as required.
Acknowledgement
Initial profiling mechanism was supplied courtesy of Bernhard Gschaider.

Field mapping function object

The new mapFields function object enables field values to be mapped to a secondary mesh at run time. If performing, e.g. flow cases where the aim is to map field data onto a coarser mesh, this object can save a lot of disk space.

The function object is specified in the controlDict using:

meshInterp1
{
    type            mapFieldsFO;
    functionObjectLibs ("libutilityFunctionObjects.so");
    outputControl   timeStep;
    outputInterval  1;

    mapRegion       coarseMesh;
    mapMethod       cellVolumeWeight;
    consistent      yes;

    fields          (U); // ("U.*" "p.*");
}
An example output for the lid-driven cavity example is shown below.

[Picture]

Example
Channel: $FOAM_TUTORIALS/incompressible/icoFoam/

Source code
$FOAM_SRC/postProcessing/functionObjects/utilities/mapFields

Ensight surface input and output

A new ensight surface reader has been implemented, accommodating both ascii and binary formats. This is currently being used in the new surfaceNoise developments more...

The ensight surface writer has also received a number of updates for binary file writing and handling of special characters.