i.e., there is no distinction between the "API version" and the
"Release version" anymore. IMO, the split scheme is just confusing for
no benefit because we are handling API/ABI changes in a pretty relaxed
manner anyway: i.e., whenever the "release version" gets incremented,
the "API version" needs to follow suite!
This reverts commit 1cf745943a. After a
more thorough investigation, the cannonical name of these quantities
turned out to be "* formation volume factor"...
This is only relevant for the approximation which uses large instead
of infinite fugacity coefficients for immiscible components. The
motivation is to bring the solution of the NCP flash solver closer to
what's expected using the blackoil assumptions directly. (Physically
speaking, the result is less realistic in most cases, though...)
i.e., interpolate between inverse volume factors and the inverse of
the product of the volume factors. I have my doubts if these
"optimizations" make the results physically better, but it seems like
they at least make things different...
these were unused, quite likely broken and could only calculate the
derivatives with regard to some quantities.
if the general derivatives of the relperms and capillary pressures are
ever required, finite differences can be used to save the
day... (these *might* be sightly slower, but they are automatically
consistent with the function.)
at least it seems to be very similar for SPE1. the difference in the
BHP of the wells for SPE1 is significantly reduced (but still too
large) by this...
this is much closer to how things are done in Eclipse. For the
external API, nothing changes provided that only the "official" fluid
system API is used...
now the values for X and Y can be added in ascending or descending
order. The descending code path is pretty slow though, and it is still
possible to screw up the object by specifying the inputs in a totally
unsorted manner. (At this place, I don't really care about these two
things, though.)
... instead of just assuming some arbitrary behavior. this fixes SPE9
for eWoms as far as the fluid system is concerned. (the ecl_blackoil
still seems to have some problems with anisotropic permeability. this
will hopefulls be fixed soon.)
currently, this can't happen because opm-material depends mandatorily
on opm-core which in turn requires opm-parser. In the future, this
might change, though...
because it seems like what eclipse uses in the DENSITY keyword is not
really for surface pressure but at the pressure where the phase's
formation volume factor is one. (this pressure does not seem to be
specified and can potentially be different for every fluid phase.)
Thus rename surfaceDensity() to referenceDensity() and remove the
logic to allow volume formation factors which are not equal to one at
the reference pressure. (i.e., formerly the surface pressure.)
it used to be the range of the sampling points. If for some reason the
sampling points describe a subset of the full range, the material laws
use extrapolation outside of the table and properly limit the values
of that operation.
In the real world, the effect of this change is rather limited because
all tested tables used the range...
TODO: adapt the evalDerivative() methods. This is not very urgent, though
because they are usually not used...
compared to the variant which uses linear interpolation, this makes
the resulting curves smoother and thus hopefully improves the
convergence rates of the simulations.
this compiler is for some reason not able to determine the number of
phases for externally defined attributes the way it was done. this is
most likely a compiler bug (or it is a left-over ideosyncrasy from
c++-2003 which was not yet removed for GCC 4.4...)
it is slightly hacky that the ParameterCache is used to specify the
PVT region. Having said that, the multiple PVT regions stuff in no way
based on physical assumptions, but is just a way to fit the black-oil
model to the measured values of real reservoirs...
I thought about this a bit and came to the conclusion that since the
composition of oil is already fixed in that context, only the pressure
dependance needs to be included in addition.
- the StaticTabulated2DFunction class and the base class
(Tabulated2DFunction) are gone
- the DynamicTabulated2DFunction class has been renamed to
UniformTabulated2DFunction
- a new class called UniformXTabulated2DFunction has been
introduced. Like UniformTabulated2DFunction, it assumes uniform
intervalls of the sampling points in X direction, but in contrast to
UniformTabulated2DFunction, the Y locations of the sampling points
can be set freely (as long as they are specified in increasing order
for each x value)
- add a unit test for the two tabulation classes
