so far, the tolerance passed to the solve() method has been silently
ignored. Besides this, the approach to determine the tolerance if none
was given is changed and a negative value is used to indicate that the
tolerance should be determined automatically.
*meaculpa!*. so far, this did not matter because the geometricMean() function was
is not used within opm-material yet. (or rather the results are
ignored.)
IMO, the gas mass fraction is more natural, but given the fact that
E100 is all about Rs, this simplifies using opm-material's PVT
relations in opm-autodiff.
this occured if threepoint scaling was enabled and the last two
saturations were identical. I'm actually not sure if the deck is valid
in this case (should not twopoint scaling used in this case?), but it
seems like it occures in Real Life (TM) and it is accepted by E100, so
let's do the same. (Note that the behavior of E100 may still be
different if the two last scaled saturation endpoints are identical
and the unscaled ones are not, or vice versa. In that case, the input
data is quite certainly rubbish, though.)
the simplification is that there is now only one code path regardless
of whether an Evaluation or plain scalars are used.
the warning removal patch broke the extrapolation case for values
smaller than the minimum value.
- move the oil relperm for connate water to the parameters. this
improves performance slightly. (although I have some doubts that the
effect is measurable in real world simulations.)
- clarify some comments
- remove unneeded parameters from the parameter object of the Stone1
material law. (reduces memory consumption slightly.)
It looks like the equations that scale the saturations for the Stone 1
model given by the Eclipse documentation are wrong. ("wrong" in the
sense that they seem not to be the ones implemented by E100).
With this change, the oil relperm seems to be identical to the ones of
E100 for SPE-1 based test deck. I'd be grateful if somebody else could
have look at this before it is merged.
the first reason why it failed was that the parameters are now
per-element instead of per-satregions. (this was merged after this was
written.) The second issue was a problem in the deck data: according
to the ECL reference manual (or the technical description, I don't
remember), the maximum relperms for the water and for the gas phase
must be equal, but in the test's decks they were not.
- 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
This simplifies the satfunc initialization code paths considerably and
avoids troubles with SWATINIT if endpoint scaling and hysteresis is
disabled. on the flipside it now requires more memory in the simple case.
It seems to me that the usual proverb about optimization holds once
more: Say 99.5% of all time: premature optimization is the root of all
evil.
