v2112: New and improved usability

Output of default parameters

TOP

OpenFOAM cases can be simplified by taking advantage of default dictionary values. Whilst convenient, it does mean that examining the input dictionary files will not provide a complete picture about which parameters were actually used for a particular simulation.

The writeOptionalEntries information switch will output the default entries. This is typically combined with the -dry-run option to limit the output to a single time step.

As an example, issuing:

rhoSimpleFoam -dry-run -info-switch writeOptionalEntries

produces the following output:

Selecting thermodynamics package 
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       sutherland;
    thermo          hConst;
    equationOfState perfectGas;
    specie          specie;
    energy          sensibleInternalEnergy;
}

-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties" Entry: "dpdt" Default: 1
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.inlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.inlet" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.outlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.outlet" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.(?i).*walls" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.(?i).*walls" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.inlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.inlet" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.outlet" Entry: "phi" Default: phi
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.outlet" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.(?i).*walls" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.(?i).*walls" Entry: "patchType" Default: 
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.specie" Entry: "massFraction" Default: 1
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.thermodynamics" Entry: "Tref" Default: 298.15
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.thermodynamics" Entry: "Href" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "system/fvSchemes.geometry" Entry: "type" Default: basic

 

Extended dictionary keywords and directives

TOP

New #message directive

The new #message dictionary directive allows reporting of expanded string content to stderr. This can be useful to add/extract information into log files, or when debugging more complicated dictionaries, e.g.

T
{
   solver          PBiCG;
   preconditioner  DILU;
   tolerance       1e-10;
   relTol          0;
   #message "Using solver: $solver"
}

New #word directive

The #word dictionary directive can be used to create dictionary names or other entries based on other dictionary elements. The content is expanded as a string and added as a validated word into the dictionary. Some examples:

#word "some_prefix_solverInfo_${application}"
{
    type    solverInfo;
    libs    (utilityFunctionObjects);
    ...
}

Or as a multi-line entry (since it automatically squeezes out non-word characters):

#word
{
   some_prefix_solverInfo
   /* Appended with application name (if defined) */
   ${application:+_}  // Use '_' separator
   ${application}     // The application
}
{
    type    solverInfo;
    libs    (utilityFunctionObjects);
    ...
}

Extended embedded prefix for regular expressions

In addition to the (?i) prefix for regular expressions to ignore upper/lower case when matching, it is now also possible to have a (?!) prefix to negate the matching. Both can also be combined together, e.g.

// Anything that does not contain "processor":

    "(?!).*processor.*"

// Anything that does not start with "wall" or "Wall" etc (ignoring case):

    "(?!i)wall.*"

 

Updated compiler support

TOP
  • Added new make rules for Nvidia compilers (PGI will soon be defunct).
  • Update to c++14 standard for most compiler rules, except gcc. This change helps when using some external third-party libraries, several of which now require c++14 compatibility.
  • The gcc definition however remains with c++11 for now, since there are many cluster installations that have gcc-4.8.5 deployed (for example, centos-7). These older versions of gcc do not support c++14. If you have a much new gcc compiler, you can simply edit the content of wmake/rules/General/Gcc/c++ to change from c++11 to c++14 without problem. Hint: use gcc --version to check which version you have available.

Extended compile controls

TOP

The handling of WM_COMPILE_CONTROL has been extended to support different compiler variants. For compilers such as gcc and clang, it is reasonably common to have several different variants installed on the computer. The version=... content from WM_COMPILE_CONTROL is used to select the appropriate compiler suffix, e.g.

WM_COMPILER=Gcc
WM_COMPILE_CONTROL="version=8"

# Compiles with "gcc-8" and "g++-8"

It can be good practice to also tag the output directory names with the version as well, e.g.

WM_COMPILER=Clang110
WM_COMPILE_CONTROL="version=11.0"

Since the entries in WM_COMPILE_CONTROL are essentially free-text, it is possible to combine with other tuning flags, e.g.

WM_COMPILER=Gcc
WM_COMPILE_CONTROL="version=8 +gold ~openmp"

# Compiles with "gcc-8" and "g++-8", uses the gold linker, but disables openmp

 

Improved tuning of etc/config and compiler setups

TOP

Handling many combinations of different systems, compilers, MPI vendors/versions and different third-party libraries is rarely an easy task. However, this version adds and extends different ways to manage complex setups.

To handle an entire group of third-party setups, the FOAM_CONFIG_ETC environment variable can be defined. It specifies a directory hierarchy that is checked before the regular OpenFOAM etc/ directory. It can be relative the OpenFOAM directory, or an absolute directory name. This is being used, for example, in the easybuild setup where it sets the FOAM_CONFIG_ETC in the etc/prefs.sh file:

# etc/prefs.sh

export FOAM_CONFIG_ETC="etc/easybuild"
export WM_MPLIB=EASYBUILDMPI

and provides the following files with all of the easybuild-specific settings:

etc
|-- prefs.sh
|-- easybuild
    |-- config.sh
        |-- CGAL
        |-- FFTW
        |-- readline
        |-- scotch
        ...

The approach not only allows rapid deployment and switching between setups, it also ensures the site-specific changes are well documented and easily applied to subsequent OpenFOAM releases.

Hint: use foamEtcFile -list and foamEtcFile -list -etc=DIR to see the effects on the config file searching.

Improved robustness/flexibility for MPI config handling

TOP

When using system OpenMPI, it now resolves the installation root with orte-info instead relying on mpicc, which improves reliability on systems where the development environment may not be active.

To help package OpenFOAM installations with precompiled MPI vendor libraries, e.g. Intel-MPI or MSMPI, the ThirdParty opt/ directory has been added to the search locations for vendor packages.

Defining different MPI versions has also become less painful. It is now possible to specify the version as part of the WM_MPLIB specification, which also now accepts lowercase specification, e.g.

# etc/prefs.sh

export WM_MPLIB=openmpi-4.1.1  ## or WM_MPLIB=OPENMPI-4.1.1

After evaluation of the config.sh/mpi this will define the following:

WM_MPLIB=OPENMPI-4.1.1
FOAM_MPI=openmpi-4.1.1

When compiling, the mpi-rules will first load the MPI family rules (OPENMPI in this example) before trying to load any version-specific rules if they exist.

As an alternative, or for further refinement, it is possible to define an mpi-specific prefs file, e.g.

# etc/prefs.sh

export WM_MPLIB=OPENMPI  ## or WM_MPLIB=openmpi

and

# etc/config.sh/prefs.openmpi

FOAM_MPI=openmpi-4.1.1

would achieve a similar result. In some cases, it can be useful to combine this approach with the FOAM_CONFIG_ETC setting shown earlier.

Improved out-of-source builds

TOP

When compiling OpenFOAM from source there are typically two top-level directories created:

  • build/ : contains all intermediate build artifacts
  • platforms/ : contains the final (shipped) binaries

With this release it is also possible to specify an alternative build-root location in a number of different ways:

  • ./Allwmake -build-root=some-dir
  • wmake -build-root=some-dir
  • FOAM_BUILDROOT=some-dir wmake

This setting will change where the 'build/' hierarchy is created. The default behaviour is equivalent to specifying the OpenFOAM project directory.

Currently the main purpose for this additional control is to support recompilation of MPI-adaption layers for an existing read-only code base. For example,

(
    export WM_MPLIB="%{foam_mplib}"
    export FOAM_MPI="%{foam_mpi}"
    export MPI_ARCH_PATH="%{mpi_prefix}"

    export FOAM_BUILDROOT=/tmp/mpibuild
    export FOAM_MPI_LIBBIN="$FOAM_BUILDROOT/platforms/$WM_OPTIONS/lib/$FOAM_MPI"

    src/Pstream/Allwmake-mpi
)

 

Improved portability

TOP

System-dependent and user-configurable scoping characters have been applied across further applications, e.g. residual information. For example, using _ instead of : for Windows systems to avoid generating illegal file names.

More adjustments to the configure scripts and environment handling for Darwin (OSX), notably adding in a -lib option for foamCleanPath that distinguishes between LD_LIBRARY_PATH (normal) and DYLD_LIBRARY_PATH (Darwin).

See the Developer Upgrade Guide for more details.