they are now called materialLawParamsPointerReferenceHack() and
oilWaterScaledEpsInfoDrainagePointerReferenceHack() which -- in my
opinion -- describes better what they do and which are also
sufficiently clunky and scary names to deter people from using them.
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.
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...)
opm-parser#677 changes the return types for the Deck family of classes.
This patch fixes all broken code from that patch set.
https://github.com/OPM/opm-parser/pull/677
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.
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.
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.)
- 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.
- 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.
the differences are not huge, but they can be seen...
(note that the "almost" match of the summary files with Eclipse is
still accomplished, but the "spot-on" match with the current opm-core
saturation functions goes away.)
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.
