OpenFOAM® v1612+: Build process

Updated build process

Executive summary

• Centralized/harmonized configuration
• Command-line tool for making common adjustments.
• Use the Allwmake with the -log option from the top-level OpenFOAM directory to capture the output for later diagnosis.
• Extensive build information in ThirdParty BUILD.md

Robustness improvements

• Ensure matches in label/scalar sizes between third-party components and what OpenFOAM expects.
• Rationalized library names lib/ vs lib64/ for third-party components to ensure that the names are consistent between its newest and previous versions.
• Cleaning configuration clutter by reducing the number of variables where possible and avoiding hidden logic. For example, now 3 instead of 5 variables for configuring ParaView.

Consistency improvements

• The definition of the software versions for ThirdParty packages has now been centralized under the OpenFOAM etc/config.sh/ directory.
• For most of the build scripts, the default software version is provided by an appropriate OpenFOAM etc/config.sh/... entry. This approach avoids duplicate entries for the default versions and ensures the best overall consistency between the OpenFOAM installation and its corresponding third-party installation.

Updated path configuration

Reconfiguring OpenFOAM to use different third-party software versions can be rather daunting, with many individual files to be edited. The bin/tools/foamConfigurePaths script provides a simple command-line interface to change the config.sh file contents.

This is an important step to automate installations and consistently package binaries. Obviously, not all parts of OpenFOAM can be easily configured with a single script, but foamConfigurePaths aims to tackle the most common variants. The build script in the Community repository further simplifies the procedure and includes scripting for the foamConfigurePaths script!

The available configuration options:

Third party component locations

In addition to specifying which version of a third-party software to use, we also need to handle situations where:

• the third-party software is already available as part of the operating system, or
• not provided by the operating system but provided in a central location, e.g. the modules package is a common approach used at data centers, or
• the software is either not available or simply not wanted.

To handle these different situations, the specification of the software receives two variables: a version variable to specify the software name/version, and an arch-path (architecture path) variable for its installation location.

The version variable generally only exists within the confines of own config.sh file, but is also used by the ThirdParty build scripts to obtain information about the configured version. In contrast, the arch-path variable is exported as a shell variable for use in other parts of the build system.

To understand how these combinations work, let’s examine potential configurations for FFTW.

The corresponding configuration file happens to be the etc/config.sh/FFTW file.

A ThirdParty configuration of FFTW, as package name fftw-3.3.5

Explanation

The makeFFTW script interrogates the config script to obtain the version. It tries to build the corresponding source directory fftw-3.3.5 located under ThirdParty, placing the resulting installation under the directory specified as FFTW_ARCH_PATH.

Later when building things that need FFTW, the FFTW_ARCH_PATH will contain include/ and lib/ (or lib64/) sub-directories.

FFTW from the operating system, e.g. as apt or rpm package

Explanation

The makeFFTW script interrogates the config script to obtain the version. Since the version is ’...-system’, it recognises that it shouldn’t build anything.

Later when building things that need FFTW, the FFTW_ARCH_PATH is checked for an include/ directory that has an fftw3.h header. Since this fails, it checks if the FFTW_ARCH_PATH is "...-system" and then verifies that the /usr/include/fftw3.h system header exists.

Even although the FFTW_ARCH_PATH is invalid, the compile and link is successful since the standard paths for include and library do contain the required values.

FFTW from the central location, e.g. loaded via modules. Here, the environment values depend heavily on the system, but could resemble:

where the FFTW_HOME is coming from the modules system in this particular example.

Explanation

As before, the makeFFTW script interrogates the config script and finds that it provides a ’...-system’ version and will not try to build anything.

Later when building things with FFTW, the FFTW_ARCH_PATH contains the needed include/ and library directories.

The final example is the easiest

Explanation

This time the makeFFTW script finds that it provides a ’...-none’ version, which tells it not to build anything.

Later when building things with FFTW, the FFTW_ARCH_PATH is invalid, does not end with "...-system", so fftw will not be used.