Extrapolate liquidDensity for unreasonable
pressure/temperature (Brine) and in UniformTabulated2DFunction.
In the current code the interpolation actually already works if the
values are outside of the tabulated region.
With this change there is now an additional function parameter
If it is true we will interpolate for every value instead of throwing
and aborting (was the case always before).
to create a constant, there are now always the three functions
Opm::constant<Eval>(value);
Opm::constant<Eval>(numDeriv, value);
Opm::constant<Eval>(x, value); // with 'x' being the 'template' of the returned value
If a given call does not make sense, an exception is thrown:
- Plain floating point objects like `float`, `double` or `quad`
complain if the specified number of derivatives is not zero.
- Statically sized evaluations throw if the specified number of
derivatives of passed to the function is not equal to their static
size.
- Dynamically sized evaluations complain if the number of derivatives
cannot be determined.
The third variant of `Opm::constant()` works unconditionally. The
`Opm::variable()` helpers are modified analogously.
... because every 2D function depends on two variables which are
usually called X and Y. The name of that class is still clunky,
suggestions are appreciated.
(also, UniformXTabulated2DFunction is a bad name. I also take
suggestions for that.)
this creates an uninitialized "compatible" evaluation that is
compatible with its argument. For primitive floating point types and
statically-sized Evaluations, this is identical to calling the default
constructor, for dynamically sized ones, it creates an uninitialized
Evaluation object of identical size as the argument.
thanks to [at]GitPaen for the heads up.
Dune::set_singularity_limit() has been removed there and std::real()
gets used by the dense matrix-vector code (this causes trouble if
`quad` is selected as scalar type)
the problem is that some of these function names clash with those for
code using AutoDiffBlock. This is normally not a problem because of
the SFINAE rule, but the static assertation makes the compiler bail
out before SFINAE kicks in.
IMO this is a little unfortunate because without this static_assert
compiler errors are bound to becomming quite a bit more obscure, but
as long there is code which uses both AD approaches at the same time,
I cannot see a way to keep the assert without moving one approach or
the other to a different namespace (or renaming the math function for
one).
this patch converts to code to use the convenience functions instead
of the math toolboxes whereever possible. the main advantage is that
Opm::foo(x) will work regardless of the type of `x`, but it also
reduces visual clutter.
also, constant Evaluations are now directly created by assigning
Scalars, which removes further visual noise.
while I hope it improves the readability of the code,
functionality-wise this patch should not change anything.
i.e., we should not return references and we also should remove the
const qualifier in this context. (if these are wanted, the calling
scope should add them.)
