Most H2 properties are calculated using Helmholtz free energy EOS.
Moved Helmholtz equations from Brine_H2 to H2 class.
New file with simple H2 property calculations based on ideal gas.
this way we don't have to drag 6MB of tables into multiple compile
units. some flexibility is lost (ie the template parameter for the
table), but this is unused in the current code.
comment out some templates that do not instance as they are referring
to non-existent table members.
it should be up to instance sites to make every available for
the templates to instance properly, even though we know we are
instancing over Evaluations.
Extrapolate liquidDensity for unreasonable
pressure/temperature (Brine) and in UniformTabulated2DFunction.
In the current code the interpolation actually already works if the
values are outside of the tabulated region.
With this change there is now an additional function parameter
If it is true we will interpolate for every value instead of throwing
and aborting (was the case always before).
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.
