now if the object is initialized using the initFromDeck() method, a
call to initEnd() is not required anymore. IMO, this makes the API
easier to use and more bullet-proof.
i.e., after this all headers are supposed to be fully autonomous again
and can thus be included without preconditions. this property broke
when OPM/opm-parser#656 was merged.
for some unit tests the precision of `float` is insufficient. To at
least enforce that the tested code compiles with `float` as Scalar,
they are wrapped by `while(false)` statements.
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)...
the recent table refactoring replaced the compile-time-safe approach
to columns (i.e., table.getFooColumn()) by a generic method which
requires a magic cookie (i.e., table.getColumn("FOO")). Unfortunately,
this went belly-up with the viscosity column of the PVTO table (here
the magic constant is "MU" and not "MUO". Note that in this respect,
opm-parser is inconsistent w.r.t. the column of the formation volume
factor which is called "BO" and not "B".)
there were also some additional typos: the gas dissolution factor is
"RS" and the pressure of oil is "P".
It probably gets time to make the opm-core/opm-autodiff PVT code use
the stuff from opm-material so that this receives some run-time
testing with `flow` during development. (currently this is only used
by `ebos`...)
these were added to make sure that the input data confirms to what is
required by the ECL documentation. It is better to do these
consistency checks externally, though. (and also not just in debug
mode.)
hopefully this fixes all of them. While doing this, I noticed that the
warnings produced by GCC 5 and GCC 4.9 differ. I did not try to
compile it with GCC 5, though.
for the most common case (i.e., Scalar == double) the previous method
lead to a tolerance of 10^-3 (relative) which is way too much if an
absolute tolerance of 10^-8 kg/(m^3*s) is required by the model.
- avoid the discontinuity between saturated and undersaturated
hydrocarbon density and viscosity. This introduces a dependency of
density and viscosity on the saturation of gas and oil which does
not make much sense from a physical POV. (note that the dependency
on the phase saturations was already there, but it was a
discontinuous one, i.e., it dependeded on S_{o,g} > 0 instead of on
S_{o,g})
- fixes for the fugacityCoefficient() method (it now also works for
wet gas and dead oil, i.e., it avoids a division by zero for
immiscible hydrocarbon phases.)
i.e., the PVT region index is passed directly to them and the
ParameterCache objects are not required. also:
- convert all methods to fluid states instead of passing the dependent
parameters directly.
- do no longer encode the phase or component names in the method names
of the fluid system.
- they are not concerned with fugacity anymore:
- as a consequence, they are now more self contained:
- they do not need to know the molar mass of each component anymore
- they do not need to call methods of the other PVT classes
anymore (that was only needed to be able to calculate the
fugacity coefficients consistently.)
- quite a few methods could be removed
- also, some methods where renamed for consistency.
this is *NOT* equivalent to the equation given by the ECL
documentation, but it makes it possible to compare it with the current
implementation. (also, the differences are pretty small: about < 10^-8
for SPE3.)
this eliminates minor differences with the current opm-core PVT
classes which were due to extrapolation of the untersaturated
tables. (Also, the result should be slightly faster if both, oil and
gas are present.)
I'm not really sure if this is always a good thing, though: It implies
discontinuities at the saturated <-> undersaturated transition which
may sometimes deter convergence rates of the non-linear solver.
