The motivation for this PR is that currently the build fails on my
Ubuntu 17.10 laptop with two processes because that machine "only" has
8 GB of RAM (granted, the optimization options may have been a bit too
excessive). under the new scheme, each specialization of the simulator
is put into a separate compile unit which is part of
libopmsimulators. this has the advantages that the specialized
simulators and the main binary automatically stay consistent, the
compilation is faster (2m25s vs 4m16s on my machine) because all
compile units can be built in parallel and that compilation takes up
less RAM because there is no need to instantiate all specializations
in a single compile unit.
on the minus side, all specializations must now always be compiled,
the approach means slightly more work for the maintainers and the
flow_* startup code gets even more complicated.
in particular, this implied some changes to the MPI initialization
code. since dune-fem's GridPart class currently has issues with
CpGrid's implementation of loadBalance(), parallel computations still
do not work if dune-fem is around, but at least sequential ones now
do even if MPI is enabled.
this is needed to avoid linker errors if this class ought to be used
in multiple compile units. IMO the main problem here is the use of an
_impl.hpp file.
Previously, QUIET was passed to opm-common which would
not even print a message if there is a problem. Now cmake
will fail if OPM_COMMON_ROOT is not set, and neither guessing
opm_common_DIR did work nor searching in the default locations.
If sibling search is activated and opm-common_DIR is not set, then
we try to determine the build directory layout from ${PROJECT_BINARY_DIR}.
The following two possibilities are supported:
+ <modules-build-dir>/<project-name>
+ <project-name>/<build-dir>
where <project-name> is the case sensitive module name (in this case
opm-common).
This results in the following search precedence:
1. User set opm-common_DIR
2. sibling directories search (if the directories exist)
3. Default (system) CMake search path
Somehow this was never called in the OPM modules. But the CMake documentation
actually says:
"The top-level ``CMakeLists.txt`` file for a project must contain a
literal, direct call to the ``project()`` command; loading one
through the ``include()`` command is not sufficient. If no such
call exists CMake will implicitly add one to the top that enables the
default languages (``C`` and ``CXX``).
"
Without it some variables (like CMAKE_PROJECT_NAME) are not correctly defined.
