"1D function tabulation classes" means 'Opm::Spline' and
'Opm::Tabulated1DFunction'.
note that 'sortInputs' is a slight misnomer because these setter
methods still expect the arguments to be given in either ascending or
descending order of the 'x' values and if they are given in descending
order, the order internal copies of these arrays are reversed. a full
sort would be a bit more work because it requires to sort two
independent arrays synchronously.
as far as I can see, the splines were only used to get a good initial
guess for the R(p) inversion code, so it should be safe to replace
them by piecewise linear functions.
The ECL Leverett function implementation "misuses" the pressure column
of the underlying tables (SWOF, SGOF, SWFN, etc.) for the
(dimensionless) J-Function. The correct converstion factor is now
applied in the parser and no converstions is needed no the opm-material
side.
this allows to explicitly query if the fluid system has already been
initialized or not. the motiviation for this patch is that this method
can be used to avoid initializing the fluid system multiple times.
valgrind complained about it. this is only relevant if initFromDeck()
is **not** used to initialize these objects. (e.g., this is the case
for the reservoir_blackoil_* tests of eWoms.)
from my point of view, the main advantage is that the string
processing for the 'flag' and 'direction' items does no longer need to
be done by opm-material.
our oldest supported compiler (GCC 4.8) now has good enough constexpr
support and c++-2011 and above seem to use constexpr for the numeric
limits of the standard floating point types.
we must not update these parameters because the respective objects do
not exist in these cases. As far as I can see, both saturation function
objects need to exist for the gas-water twophase case despide the fact
that there is no oil because the capillary pressure between water and
gas is the sum of the capillary pressures between gas+oil and
oil+water. (also, I am not aware of any ECL keywords to provide the
gas-water saturation functions directly.)
if this specialization is not marked as "inline" it leads to linker
errors due to multiple definitions of the
`Opm::className<__float128>()` symbol. I consider this pretty
surprising behaviour of the C++ language because template functions do
not need to declared as `inline`.
this allows the test suite of eWoms to be compiled on clang++ 3.8
using the following warning flags
```
-Weverything
-Wno-documentation
-Wno-documentation-unknown-command
-Wno-c++98-compat
-Wno-c++98-compat-pedantic
-Wno-undef
-Wno-padded
-Wno-global-constructors
-Wno-exit-time-destructors
-Wno-weak-vtables
-Wno-float-equal
```
without triggering warnings in opm-material or eWoms.
Note that the test-suite for opm-material does *not* yet pass without
warnings with these flags because with these flags clang likes to
complain about reducing or increasing floating point precision which
results in a formidable nightmare. I will see what I can do about
these warnings in a separate PR.
v4: properly fix the unused parameter warnings for the valgrind client
requests. thanks to [at]atgeirr for finding the issue.
this allows some flexibility of how an Evaluation object is
represented internally. the main motivation for this is to allow using
SIMD instruction which expect special data types as their operants.
