Mostly one would assume that this would be the porosity since that's the
only non-named argument, but stating this explicitly saves us from one
trip to the manual.
This file can be included both in the project itself, and also in the
find module for the library, so that the list of dependencies can be
maintained in only one place.
The <have_boost_redef.hpp> header was introduced (commit 82369f9) as
a work-around for a particular interaction in the Autotools-based
setup of OPM-Core and the Dune core modules. Notably, Dune's
"Enable" trick for Boost failed on some older Autoconf systems. Now
that we're using CMake, however, that kluge is no longer needed
because we (OPM-Core) always
#define HAVE_BOOST 1
i.e., as an explict true/false value.
Therefore, we need no longer include <have_boost_redef.hpp> . The
header will be removed at a later time.
After this patch one can set the prolongation factor for all
AMG calls and the number of smoothing steps for all except
of FastAMG that currently only supports on step.
This let you specify a bunch of directory names on the command line
to *all* packages, without getting annoying warnings that they are
defined but not used.
When using LTO, the linker calls back to the compiler to figure out
where a certain symbol is defined. However, in many versions there
is apparently a bug that is triggered if a template in inlined in
both a used library and in the main program, but with different
versions of the compiler. The Boost exception class is particular
prone for this.
Thus, we disable the -lto from the development builds by default;
if anyone wants to test of the behaviour of their own compiler, they
must now explicitly turn on this flag.
For older OpenSuSE versions (12.1 comes to mind), the packages mentioned
here are only available in the repository and not the base distro, so we
should start out by adding it instead of doing it later in the process.
Variably-sized arrays of the form
int n = 6;
double a[n];
are an extension to the language that will illicit a suitably
persnickety diagnostic from GCC when invoked with "-pedantic".
The numbers in the deck are more indicative of FIELD unit conventions
than METRIC unit conventions, so allow the input parser to interpret
the data in that manner.
The executable is not written as a unit test (e.g., using Boost.Test)
and furthermore requires external data (in a very specific location).
This makes it inappropriate for use during "make test", but it could
(and should) be cleaned up and incorporated into the test portfolio at
a later time.
