OpenFOAM® v1612+: Interoperability
23/12/2016
External applications
Users implementing their own code extensions now have the ability to accommodate multiple OpenFOAM versions using a new pre-processor directive.
It is often not possible to migrate code in its entirety to a new OpenFOAM version, particularly if the code targets multiple versions. Most commonly there is a transition period during which the developer will want to test the extended functionality.
The new pre-processor macro OPENFOAM_PLUS is automatically defined as part of the OpenFOAM wmake rules and paired with the OpenFOAM release. It comprises a 4-digit identifier corresponding to a linear API-level, equal to the currently compatible version number, e.g. to help migrate code the following can be used:
#if (OPENFOAM_PLUS >= 1612)
...
#endif
...
#endif
Experienced users will recognize that the #ifdef... cascades should be used sparingly and do not replace a proper version control system. Nonetheless, they can be extremely helpful during a transition period.
The baseline API levels, i.e. 1612, 1706, 1712, …are set by the June and December release schedule. Any bugfix releases that do not significantly affect the compile-time API retain the same API level until the following scheduled release. For users following the *development* branch, larger API changes are indicated by a change in the API number to the month in which those API changes were finalized.
Binary files
Previously a bit of trial-and-error was required to determine if an OpenFOAM binary file had been written in single or double precision, or use 32-bit or 64-bit labels. This is unnecessary annoying for the end-user and for any third-party software providers.
To resolve this problem, the OpenFOAM binary files are now emitted with an additional arch (architecture) hint in the FoamFile header. The arch specification indicates the machine endian (LSB |MSB), the label width (32 |64) and the scalar precision (32 |64).
FoamFile
{
version 2.0;
format binary;
arch "LSB;label=32;scalar=64";
class vectorField;
object points;
}
{
version 2.0;
format binary;
arch "LSB;label=32;scalar=64";
class vectorField;
object points;
}
The endian information shall appear as the first element in the list, which makes it easy to check. The ordering of the label and scalar elements is arbitrary, but the quoteTextkey=value format shall be used. The individual elements can be delimited by colons, semi-colons, commas, or spaces, e.g. any of the following are considered valid:
"LSB; label=32, scalar=32"
"MSB ,scalar=32; label=32"
"MSB: scalar=32 label=32"
"MSB ,scalar=32; label=32"
"MSB: scalar=32 label=32"
This architecture information is currently only emitted and not checked when OpenFOAM reads the files, but architecture type checking will be add into IOobjects in the very near future.
Other
base64
The new base64 encoding layer can be attached to any currently open output stream when generating base64 content, for saving to disk or streaming to applications consuming such content.
C-strings
A new set of adapters for translating between a list of C++ strings to and from a list of C-style strings.
- Translates a list of C++ strings into C-style (argc, argv) pair.
- Translate C-style (argc, argv) pair to list of C++ strings.
This useful when interacting with external C-code and some libraries.