The CO2BRINE model is activated by setting CO2STOR in the RUNSPEC section
The CO2 and brine pvt properties are computed based on pvt models in opm-material
- CO2 density is from Span and Wager (1996) as given in co2table.inc
- CO2 viscosity is from Fenhour et al (1998)
- Brine density and viscosity is based on H20 + correction based on Batzle and Wang (1992)
- H20 density is from Hu et al (2007)
- H20 viscosity is computed from density based on correlation given in IAPWS 97
At the current stage the oil-phase is used to model the brine. If a proper gas-water
simulator is made, the Brine PVT should be moved to the water phase.
Known limitations:
- Currently the viscosity of the Brine does not depend on the composition
- Salinity is assumed to be constant and given by SALINITY [mol/kg].
this has mildly annoyed me for quite some time, and finally managed to
bring myself to changing it: The Opm::FluidSystems namespace is pretty
useless because the number of classes contained within it is quite
small and mismatch between the naming convention of the file names the
actual classes is somewhat confusing IMO. Thus, this patch changes the
naming of fluid systems from `Opm::FluidSystems::Foo` to
`Opm::FooFluidSystem`.
(also, flat hierarchies currently seem to be popular with the cool
people!?)
this patch requires some simple mop-ups for `ewoms` and `opm-simulators`.
I missed the fact that in the enthalpy() function, the polynomial
coefficients are divided, i.e., this component defines a polynomial
for the heat capacity and integrates it for the enthalpy. (not
the other way around.)
I looked at all components: For the ones that use simple enthalpy
relations, heatCapacity() and enthalpy() should now be
consistent. (Here "simple" means "an approach that I understood without
reading literature for several hours".)
std::exception is a polymorphic type and catching these by values
generates warnings when using the latest GCC from SVN. Besides this,
catching objects by value is bad style and was unintended from the
start.
this patch converts to code to use the convenience functions instead
of the math toolboxes whereever possible. the main advantage is that
Opm::foo(x) will work regardless of the type of `x`, but it also
reduces visual clutter.
also, constant Evaluations are now directly created by assigning
Scalars, which removes further visual noise.
while I hope it improves the readability of the code,
functionality-wise this patch should not change anything.
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 allows the test suite of eWoms to be compiled on clang++ 3.8
using the following warning flags
```
-Weverything
-Wno-documentation
-Wno-documentation-unknown-command
-Wno-c++98-compat
-Wno-c++98-compat-pedantic
-Wno-undef
-Wno-padded
-Wno-global-constructors
-Wno-exit-time-destructors
-Wno-weak-vtables
-Wno-float-equal
```
without triggering warnings in opm-material or eWoms.
Note that the test-suite for opm-material does *not* yet pass without
warnings with these flags because with these flags clang likes to
complain about reducing or increasing floating point precision which
results in a formidable nightmare. I will see what I can do about
these warnings in a separate PR.
v4: properly fix the unused parameter warnings for the valgrind client
requests. thanks to [at]atgeirr for finding the issue.
mainly these issues stemmed from the fact that floating point values
can be negative and casting negative values to unsigned integers leads
to very large unsigned values instead of 0.
IMO this is pretty cool because it allows to transparantly calculate
higher order derivatives. for example this enables to implement the
linearization stage of higher-order non-linear solvers without much
additional effort compared to just evaluating the function in
question. (essentially, such higher order non-linear solvers are based
on truncating the Taylor series not after the first term -- like for the
Newton scheme -- but later. That said, they require to solve linear
systems of equations which involve tensors of orders greater than 2,
so they are not really practical as far as I can see.)
A more practical motivation for this is to allow the constraint
solvers to be used in "nested mode", i.e., linearizing the system of
equations they need to solve using automatic differentiation, but
allowing the value objects which are passed to the constraint solvers
be function evaluations themselves. (E.g. the result of a flash
calculation can also include the derivatives with regard to the
primary variables of the flow model. Note that the individual
constraint solvers need to some patches to make this work.)
this patch removes the in-file lists in favor of a global list of in
the COPYING file. this is done because (a) maintaining a list of
authors at the beginning of each source file is a major pain in the
a**, (b) for this reason, the list of authors was not accurate in
about 85% of all cases where more than one person was involved and (c)
this list is not legally binding in any way (the copyright is at the
person who authored a given change; if these lists had any legal
relevance, one could "aquire" the copyright of the module by forking
it and replacing the lists...)
normally this is not a problem, but template functions which take two
arguments, will break, i.e., the following will not compile
```c++
float f = 1.23;
std::max(f, 2.0*f);
```
this is because the second argument for max gets silently cast to
`double` which causes the compiler to be confused because it cannot
determine a uniform type for the arguments passed to
std::max<T>(a, b)...
- add unit tests for the EclMaterialLawManager and the black-oil PVT classes
- rework the API of the blackoil PVT classes so that it follows the
initFromDeck() pattern and uses multiplexer classes instead of
dynamic polymorphism to select the concrete PVT approach
- the former change allowed to use the BlackOil fluid system with
arbitrary Evaluations, i.e., it is not limited to a single
Evaluation class which is specified as a class template argument
anymore.
- more fixes for GCC and clang warnings. now it should be reasonably
hard to trigger warnings using these compilers.
this commit squashes the following patches:
- add a unit test for the EclMaterialLawManager
- black oil: simplify the WaterPvtInterface
- add a unit test for the PVT classes of the black oil fluid system
- black oil: improvements to the PVT classes
- blackoil PVT: remove dynamic polymorphism
most of these people like to inflict pain on themselfs (i.e., warnings
in their own code), but they usually don't like if pain is inflicted
on them by others (i.e., warnings produced by external code which they
use). This patch should make these kinds of people happy. I'm not
really sure if the code is easier to understand with this, but at
least clang does not complain for most of the warnings of
"-Weverything" anymore.
they used to be in opm-core, but this allows to be more flexible with
the dependency order: What's now called "opm-core" can easily depend
on opm-material which might come in handy for the refactoring.
Besides moving in classes from opm-core, the infrastructural code
which was still in opm-material is moved to the directory
opm/material/common. The intention is to collect these classes at a
central location to make it easy to move them to a real "core" module.
(if this is ever going to happen.)
- 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
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>
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.
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...
