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.)
this is anlogous to the dry gas PVT code but it uses the PVDS and
SDENSITY keywords.
Note that this object is only used by the eWoms black-oil solvent
code, i.e. it not used by the black oil fluid system or any other
opm-material code, but IMO opm-material is the right place for it
because of its similarity to dry gas.
that warning was correct, but bogus: while this data was indeed used
without initialization, using the mass composition of a phase before
fully specifying the molar composition is incorrect and would have
trigger a valgrind complaint. (valgrind will still complain after that
patch.)
in some places, it used primitive floating point objects when it
should have used Evaluations. This is probably not the only place
where this happens, but IMO the individual components are pretty low
priority.
This method changes the saturation table idx in the original material
law parameter object. In the context of ECL reservoir simulators, this
is required to properly handle wells with its own saturation table idx.
In order to reset the saturation table idx in the materialLawparams_
call the method with the cells satRegionIdx after it has been used for
the well connection.
Hysteresis is not accounted for. Is is a open question how this should
be implemented. A warning is given if hysteresis is combined with a
modified saturation table idx for the connection.
in some places, it used primitive floating point objects when it
should have used Evaluations. This is probably not the only place
where this happens, but IMO the individual components are pretty low
priority.
