- 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.)
it seems to be implicitly included by newer compilers, but not GCC
4.4. In this case I agree with GCC 4.4...
Thanks to Bård Skaflestad for the hat-tip.
- add methods to calculate the derivatives of the capillary pressures
and relative permeabilities with regard to the phase saturations,
temperature, absolute pressure and phase composition
- extend the unit test to enforce the above
- make the NullMaterial conform to the API and add it to the unit test
- introduce Opm::NullMaterialTraits for material laws that don't use
any phase indices
They are now all generic capillary pressure laws, but with some
additional methods to make working with them easier. For this reason,
they have been moved up one directory to opm/material/fluidmatrixinteractions
Also, a unit test which ensures that all capillary pressure laws
conform to their respective APIs has been added.
this lead to a compiler warning on gcc 4.8 that this case was already
covered by catching std::exception. Since we did the same in both
branches anyway, these statements were not required...
