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
the biggest one was that the Rs factor was used incorrectly: instead
of "surface volume of gas per volume of saturated reservoir oil" it is
defined as "surface volume of gas which a volume unit of surface oil
dissolves at reservoir pressure".
Besides this, there are a few smallish improvements like the oil
density being a function which can be called without having the
boilerplate objects (i.e., the fluid state and parameter cache
objects) instantiated.
These index names have been fully fluid system dependent for a while
and are supposed to be just used for convenience. This means that
phase names are now actual camelCase words.
because fluid-matrix interactions have been independent of the number
of phases for a while. The only law left in this folder (implementing
the Parker-van Genuchten law) has been moved one folder up and been
cleaned up considerably.
Enabled access to these methods in the co2-brine-fluidsystem (only
pure-phase heat capacities are used). reviewed by Klaus
Dumux-Svn-Revison: 12462
Ported-By: Andreas Lauser <and@poware.org>
this is analogous to commit r12402 of dumux. The current approach was
doing the "compositional consideration" twice. (and the difference
between using the partial pressure for the enthalpy and using the
total one in conjunction with weighting by mass fraction should be
neglectible for "almost ideal" gases, i.e., for low pressure and
temperature scenarios.)
the macros where used to make the influence of the valgrind calls zero
even for debug builds if valgrind client requests were
unavailable. Since this resulted in some inconsistencies, and the
performance hit is not terribly large, we now always use the same
inlined functions. For optimized builds the impact of those is still
zero...
because these classes should not have any side effects. case in point:
the warnings intended to be printed once get printed once per process
which can be quite a few times for parallel simulations with thousands
of cores. This could also be avoided by checking the MPI rank, but
IMHO this is way too much boilerplate code for a feature of questionable
value.
The resize() method for std::vector seems to copy an uninitialized
object for the new objects in the array on GCC 4.4. This means that we
should not assume that the copied objects are finalized in the
Parker-Lenhard parameters. Strangely enough this only seems to affect
older GCCs (at least 4.4) and only in debug mode...
this is intended to be used for ECLIPSE saturation curves, but the
code is more generic. (Be aware that using cubic splines for the
interpolation between sampling points is probably a better choice in
most cases.)
