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.
e.g., looping over the wrong range or an infinite loop. also, the
dense-AD unit test is shortend to test one specialization and the
unspecialized class.
older compilers (-> GCC < 5) seem to have trouble with inlining here
which leads to sub-optimal performance. since it is not a big problem
to also generate the unspecialized Evaluation class, let's do that
instead. (for hand-written code, this would be a huge
consistency/maintainance problem, though.)
we now ask the tabulation class for the derivative directly and we do
not return negative saturation pressures anymore. (the latter is done
via putting the Newton method on "probation" if the saturation
pressure becomes negative. The first time it does this offense we try
to help it out of its mess, but if it happens again, we abort it and
return 0 as the saturation pressure.)
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.
