for primitive floating point objects, these correspond to
std::isfinite() and std::isnan() while for evaluations, they trigger
on the evaluation's value or any of its derivatives being non-finite
or NaN. (i.e., for evaluations they should be better called
containsnonfinite(), containsnan().)
if this is not done the generic code produces NaNs. (either by using
the result of ln(0.0) or by means of a division by zero.)
This seems to fix the linearization of flow_ebos for "Model 2".
`getValue(x)` should be better called `value(x)` but this leads to
really cryptic compiler errors which seem to be related to the fact
that the Evaluation class has a `value` attribute (this is for GCC
5.2.1).
with this, evaluation objects can be decayed via
`Opm::decay<Scalar>(x)`. since function templates do not require a
'template' qualifier, it is a bigger advantage for this function that
for the mathematical ones. (the conventional way to do this is way
more verbose:
```c++
Opm::MathToolbox<Evaluation>::template decay<Scalar>(x)
```
)
we now take the type which can by assigned by the other. this is still
not perfect because the result may be surprising for cases like
'double' and 'int', but it is much better than the situation before.
this PR was inspired by one of @atgeirr's recent comments. it allows
to get rid if the `MathToolbox<Eval>` detour for the dense AD code in
most cases: e.g. instead of writing
```c++
template <class Eval>
Eval f(const Eval& val)
{ return Opm::MathToolbox<Eval>::sqrt(val); }
```
one can simply write
```c++
template <class Eval>
Eval f(const Eval& val)
{ return Opm::sqrt(val); }
```
and it will work transparently with DenseAD `Evaluation` objects and
primitive floating point values.
one complication of this is that the type of the `Evaluation` object
does not need to be explicitly defined. for functions which take more
than one argument (like e.g. `pow()`, `min()` and `max()`), it is thus
assumed that the type of the result is the same as the type of the
first argument.
another drawback is that when both, the contents of the `Opm::` and
the `std::` namespaces are implicitly available, it is not clear to me
what's used for primitive floating point values. (it seems to compile
but IMO it could lead to surprising behaviour. thus, please only merge
if you consider the benefits of these convenience functions to be
greater than their drawbacks.)
also, only calculate a factor if the currently observed oil saturation
is smaller than the maximum oil saturation. The new code is not
completely equivalent to the old one because derivatives are not
considered if the oil saturation increases, but the differences should
be small and they should be closer to how the current master version
of opm-simulators handles VAPPARS.
they are now called materialLawParamsPointerReferenceHack() and
oilWaterScaledEpsInfoDrainagePointerReferenceHack() which -- in my
opinion -- describes better what they do and which are also
sufficiently clunky and scary names to deter people from using them.
this is yet another crazy Eclipse hack: it prevents the dissolved
component to be fully assimilated by solvent phases if the maximum oil
phase saturation seen during the simulation stays below a given
limit...
10^100 cannot be represented by single-precision floating point values
and 10^30 is large enough considering the fact that the distance from
Earth to Alpha-Centauri is "only" about 4*10^16 m...
by default, this just checks if the saturation of the incriminating
phase is larger than 0, but in some cases (i.e., black-oil) the
calling code might have a different opinion: E.g., the black-oil model
looks at the primary variables to determine the phase presence.
Since "dense automatic differentiation" describes what this code is
all about much better in my opinion. ("Local AD" is just a possible
use case in the context of PDE discretization.)
these warnings were caused by the fmatrix.hh header being included
before Evaluation.hpp. While they were harmeless, they were annoying.
(I did not discover this earlier because I normally use Dune 2.4 which
does not have this particular issue.)