OpenFOAM: v1912 released! - For more information see

Commit fc986924 authored by Andrew Heather's avatar Andrew Heather

Merge branch 'develop'

parents 65d6551f 641c8ae5

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -24,7 +24,7 @@ command -v mpirun 2>/dev/null || true
echo "========================================"
date "+%Y-%m-%d %H:%M:%S %z" 2>/dev/null || echo "date is unknown"
echo "Starting compile ${WM_PROJECT_DIR##*/} ${0##*}"
echo "Starting compile ${WM_PROJECT_DIR##*/} ${0##*/}"
echo " ${WM_OPTIONS}, with ${WM_MPLIB} ${FOAM_MPI}"
echo "========================================"
......@@ -75,8 +75,8 @@ echo " ${WM_PROJECT_DIR##*/}"
echo " ${WM_OPTIONS}, with ${WM_MPLIB} ${FOAM_MPI}"
echo " api = $(wmakeBuildInfo -show-api 2>/dev/null)"
echo " patch = $(wmakeBuildInfo -show-patch 2>/dev/null)"
echo " api = $(foamEtcFile -show-api 2>/dev/null)"
echo " patch = $(foamEtcFile -show-patch 2>/dev/null)"
echo " bin = $(_foamCountDirEntries $FOAM_APPBIN) entries"
echo " lib = $(_foamCountDirEntries $FOAM_LIBBIN) entries"
# Allwmake with scan-build (clang)
c_compiler="$(command -v "$(wmake -show-c)")"
cxx_compiler="$(command -v "$(wmake -show-cxx)")"
set -x
scan-build --use-cc="$c_compiler" --use-c++="$cxx_compiler" \
./Allwmake "$@"
Known Build Issues
Intel MPI (Gcc/Clang)
Either I_MPI_ROOT or MPI_ROOT can be used to specify the Intel-MPI
installation directory path.
The ThirdParty build of ptscotch uses `mpiicc` for Intel-MPI
instead of the usual `mpicc`.
When gcc or clang are used, it is highly likely that the
I_MPI_CC environment variable also needs to be set accordingly.
See `mpiicc -help` for more information about environment variables.
Intel Compiler
Since OpenFOAM uses C++11, a fairly recent version is required.
The Intel compiler - icc (ICC) 17.0.1 20161005 is ok, but the
initial release - icc (ICC) 17.0.0 20160721 - has a bug that
will result in these types of error messages.
MatrixSpaceI.H(492): error: no instance of overloaded function
"Foam::MatrixSpace<Form, Cmpt, Mrows, Ncols>::Block<SubTensor,
BRowStart, BColStart>::operator=" matches the specified type
If using the runTimePostProcessing to create on-the-fly images, you
can simply just compile ParaView and these libraries will be used.
If you elect to use a separate VTK compilation (for example for
off-screen rendering), it is advisable to reuse the VTK libraries that
are provided with ParaView by making an appropriate symlink
prior to using makeVTK. This doesn't just reduce disk-space, but works
much better than using the VTK tar file.
Using runTimePostProcessing with the 'plain' VTK libraries does
generally work, but does not exit cleanly:
symbol lookup error: .../linux64Gcc/VTK-7.1.0/lib/
undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
symbol lookup error: .../linux64Gcc/VTK-7.1.0/lib/
undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
This error appears to be suppressed if VTK is compiled with a Debug build-type.
Building on older systems
If the system gcc is too old for building OpenFOAM, a third-party gcc or
clang/llvm installation can be used. If building clang/llvm, note that
there are also minimum gcc/g++ requirements there:
Min gcc/g++
=========== ==========
4.4 llvm-3.4.2
4.7 llvm-3.5.2 - llvm-3.7.0
If your system compiler is too old to build the minimum required gcc or
clang/llvm, it is just simply too old.
ThirdParty clang without gmp/mpfr
If using ThirdParty clang without gmp/mpfr, the ThirdParty makeCGAL
script will need to be run manually and specify that there is no
gmp/mpfr. Eg,
./makeCGAL gmp-none mpfr-none
Subequent compilation with Allwmake will now run largely without any
problems, except that the components linking against CGAL
(foamyMesh and surfaceBooleanFeatures) will also try to link against
a nonexistent mpfr library. As a workaround, the link-dependency can
be removed in wmake/rules/General/CGAL :
This is a temporary inconvenience until a more robust solution is found.
Building with spack
If you are building with spack, note that the depends_on for paraview
resolves poorly. The +qt dependency (for building the reader module)
may need to be specified as a preference by including the following in
your `~/.spack/packages.yaml` file:
variants: +qt
It appears that spack will otherwise ignore any paraview+qt version
and attempt to install a paraview~qt version instead.
Building on Darwin (Mac-OS)
Support for Darwin is incomplete, but has been provisioned for.
The following are typical (as of yet) unresolved issues.
* Scotch, ptscotch:
- The librt linkage is required for Linux, but not for Darwin.
Current resolution:
Edit or patch
to remove the '-lrt' library
- ThirdParty CGAL will normally need to be compiled without mpfr/gmp.
This should be done manually prior to building OpenFOAM or other
ThirdParty. Eg,
./makeCGAL gmp-none mpfr-none
The erroneous references to gmp/mpfr library can be directly removed
from the wmake/rules/General/CGAL, but it is more advisable to
override them instead in the wmake/rules/darwin64Clang/CGAL file.
......@@ -3,3 +3,7 @@ build-info
# Do not track time-stamp
# Do not track any manifest files
......@@ -44,15 +44,16 @@ source archives.
- 6-digit year-month-day (YYMMDD) integer corresponding to a patch-level
for the given **released** API.
Development branches have a patch value of `0`.
- Format is year-month-day, as per `date +%y%m%d`.
- The first release is by definition unpatched, and thus carries
a patch value of `0`. If this release were to be patched the following
day, the patch level would jump accordingly.
- The first release can have a patch value of `0` (unpatched = just
released) or a patch value corresponding to the release date.