this is needed for the well model. Be aware that in the future this
will probably need to be changed to have one material parameter object
per connection instead of one per saturation region. This attitude
adjustment would be necessary to support endpoint scaling and
hysteresis in the well model, but so far it is unclear what the
reference simulator does.
"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`.
