this works by passing -1 as the template argument for the number of
derivatives. most of the code is identical, but creation of such
objects requires the number of derivatives passed to the constructor
or the copy constructor must be used.
Finally `DynamicEvaluation<Scalar>` is provided as a more expressive
alias for `Evaluation<Scalar, -1>`.
this means Carlson's hysteresis model for the relperm of the
non-wetting phase and the imbibition instead of the drainage curve for
the relperm of the wetting phase.
so far, compressed element indices have been used to access data for
logical cartesian cells. this does not matter if there is only a
single saturation region for imbibition and thus IMBNUM is
uniform. (e.g., this is the case for Norne as far as I can see.)
this used to be the unmodified quadratic function that results from
integrating a linear function. using the midpoint rule is quite a bit
simpler and should yield the same results.
thanks to [at]atgeirr for pointing this out.
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)
after #278, the generic version of getInvB_() was always used because
no argument for fluidState.invB() was specified when invoking the
GENERATE_HAS_MEMBER() macro, so has_invB<FluidState>() returned false
for any fluid state. since the getInvB_() function is not used by the
master version of `flow` yet, it was unaffected by this issue and this
is also the reason why neither Jenkins complained nor any performance
regression could be seen after #278. That said, for implementing
non-trivial boundary conditions, it is very helpful to have a unified
code path for the case where boundary conditions are specified using
generic fluid states and black-oil model specific ones as well as with
the flux computations in the interior of the domain.
Note that I only found this issue due to the fact that on my current
WIP branch linearization got 10% slower for Norne. This means that the
generic version of this function must be correct and, considering the
fact that the massFraction() method is quite elaborate for
BlackOilFluidState, this is also a very strong indication that on
modern processors the performance of even the linearization part of
the simulation is more limited by memory latency than by the execution
speed of the ALUs.
this used to be has_pvtRegionIndex(). While there currently is no
difference in practice because the only fluid state that exhibits a
pvtRegionIndex() method also has invB(), a bug is a bug...
this does only matters for temperature changes due to dissolution and
evaporization of gas in oil or oil in gas. The comprehensive solution
would be to make the enthalpy of the phases composition dependent, but
ECL does not seem to support this when using the black-oil model.
this was only partially done so far: the term "heat" should be avoided
if possible because it is a somewhat fuzzy concept. Thus, replace it
by "energy" and "thermal" where it is not a well established
term. ("well established" basically means "heat capacity".)
before, if the fluid state did not provide an invB() method,
Opm::getInvB_() just returned 0.0. with this, it uses the composition
and density of the phase in question to compute that quantity.
(also, this commit contains a few stylistic cleanups for
BlackOilFluidSystem)
now the assign() function should work and all functions should exhibit
a doxygen string. note that the inverse formation volume factors are
zero if the fluid state passed as the argument to assign() does not
feature an invB() member function.
thermal laws are the heat conduction laws plus "solid energy laws"
which can be used to specify the relations which govern the volumetric
internal energy of the solid matrix of the porous medium.