at least, don't special case that much. This caused a discrepancy with
the opm-material PVT relations for Norne after 23 report steps. (which
takes an hour or two to get to with debugging options on my machine.)
As you can probably imagine, finding this was *a lot* of fun...
I have doubts if this will change anything in the binaries (and in my
personal opinion, these 'const's look quite ugly and are sometimes a
(small) annoyance when debugging), but I don't mind using the coding
style used by most of the rest of opm-core here.
we're correcting the pressure at the cell center depths to get the
pressure at the face depth, not the other way around. This is
confusing...
thanks to [at]totto82 for discovering this.
This needs to be done if a equilibration region transition is
mentioned by the THPRES keyword, but no value is given for this record
in the third item. (it seems that this is used quite frequently.)
Also, the approach taken by this patch also does not collide with the
restart machinery as far as I can see. This is because the initial
condition is applied by the simulator before the state at the restart
time is loaded. (I interpreted the code that way, but I could be
wrong, could anyone verify this?)
since it is pretty elaborate to calculate initial condition, this
patch is pretty messy. I also do not know if Eclipse does include
capillary pressure in this calculation or not (this patch does). Huge
kudos go to [at]totto82 for reviewing, testing and debugging this.
the derivatives changed in some instances compared to the old
implementations. this patch updates them to the new versions.
thanks to [at]atgeirr for discovering this.
this caused the hysteresis saturation shifts to be initially wrong and
was probably the source of a lot of my confusion w.r.t. the saturation
scaling and hysteresis shift code. I guess this also fixes a valgrind
complaint, but I haven't checked...
"old" == "gcc 4.4". the standard c++ library of this compiler seems to
invoke the copy operator when creating objects in a vector, whereas
newer versions of the library don't. The problem is that std::unique
pointer cannot be copied because it is -- err -- unique and thus the
implicit copy operator for the SatFuncMultiplexer class gets deleted
by the compiler.
the fix is to introduce a "fake" copy operator which does not do
anything but is present to make std::vector of stdlibc++-4.4
happy. this is obviously not very elegant, but I could not come up
with a better solution. (another fix would be to use raw pointers
instead of std::unique_ptr, but IMO this does not qualify as
"better".)
basically, we now store a pointer to the base class and convert this
to the concrete incarnation of the saturation function. the only
disadvantage of this is that it requires to allocate the concrete
objects dynamically, i.e., there's another layer of indirection. On
the plus side it saves a few bytes per object and it makes things
quite a bit simpler, so it is a win IMO.
thanks to [at]atgeirr for suggesting this.
this makes it possible to switch to different saturation functions
again. So far the only supported function besides the default one is
the one which implements the "Stone 2" model.
this means the following changes:
- the "SatFuncGwseg" class is converted
- for now, Gwseg is the only saturation function supported by
SaturationPropsFromDeck. (will be changed in later commits.)
- the funcForCell() method of SaturationPropsFromDeck is removed as it
just occludes things
in any reasonable simulator which reads an ECL deck the deck is going
to decide which saturation function is to be used and not the outside
code. also, the table this which function will be using is not really the
calling code's business. (for any reasonable deck it is always going to
be a non-uniform table so it makes a lot of sense to avoid unnecessary
complexity IMO.)
this patch temporarily removes the ability to use anything except the
ECL default saturation function ("Gwseg"). this ability will be
restored later in this patch series.
namely BlackoilStateToFluidState which takes a BlackoilState object
and exposes it as a opm-material like fluid state object. Similar for
ExplicitArraysFluidState, which takes raw arrays.
since fluid states are a local API, the index of the cell to be used
for these two classes must be set externally. The advantage of this
concept is that it is possible to make "saturation functions" which
not only depend on saturations but also on arbitrary other quanties
(like temperature or phase composition) without having to change the
API of the "saturation" functions.
This is mostly infrastructural code (Opm::Spline,
Opm::TriDiagonalMatrix, property system and the cubic polynomial
inversion code) that is only used by opm-material and eWoms. The
original intention of bringing this code into opm-core was to allow
other modules to start to use this easily. Since nothing in this
direction happened during the last one and a half years, the code only
represents baggage in the opm-core context and should thus be moved to
their consumer modules to make the life of everyone involved simpler.
-O3 is sometimes declared "unsafe"
(cf. https://wiki.gentoo.org/wiki/GCC_optimization ) and it seems like
it bit us in https://github.com/OPM/opm-material/issues/23 if GCC 4.8
was used. so let's play safe and use -O2 for now...
basically, the unit system was reversed for rates and a
UnitSystem::UnitType object was implicitly casted to bool for the
bottom hole pressure monitor. (if the BHP monitor worked, it was only
by accident...)
I'd prefer to pass it for consistency reasons (because basically every
other class which takes an EclipseState object also requires a deck
object), but some people seem to have a very strong option about
this...
or more accurately: "use FIELD or METRIC units", LAB and PVT-M units
are still unsupported, but they seem to be pretty exotic and are also
not supported by opm-parser either...
note that this patch requires an API change (with the usual
consequences for all downstream modules which use this class) because
the deck needs to be passed to EclipseWriter. If somebody knows a
canonical way to get the names of the written units from EclipseState,
this is API change is not required.
I used "TEMP" as the name of the field of the UNRST files, but that is
just a guess. (I don't have access to any results of a thermal run of
the "It Defines The Truth (TM)" simulator.)
instead, we will be going with wrapper classes around the PvtInterface
in the next commits. this considerably reduces the amount of
copy-and-paste required for temperature support.
this is implemented such that if the simulation is unchanged,
viscosities are assumed to be not temperature dependent. (only if
pvtObject->set{Oil,Wat}visctTables() is called, temperature dependence
is considered.)
as far as I can see, it provided M4 macros for autotools based
projects which wanted to use OPM. I have severe doubts that this was
used by anyone because it most likely does not even work. (e.g. the M4
macros does not seem to specify the ERT and opm-parser prerequisites.)
Note that I'm not 100% sure of the above, so if I'm wrong, state so
loudly and I'll close the PR...
the reason is that the tools for profiling and for coverage analysis
(i.e., gprof and gcov) have trouble with this and crash. if you want
this to be enabled for whatever reason, use the cmake flag
-DSTRIP_DEBUGGING_SYMBOLS=ON or pass configure the
--enable-strip-debug option.
this is now done by a config.h macro. The reason is that quite a bit
of code depends on boundary IDs which are only available as an
"experimental" grid extension in recent Dune releases...
first this makes the test very slow, second (and more importantly) it
makes the test fail on dune master as the header relies on the
presence of the DUNE_GRID_VERSION* macros which are not present at the
configure stage of the build...
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
because if that is done, the integration for the production total is
wrong because the time step length is days and not seconds.
Note that the conversion now uses Opm::unit::convert::to(<>,
1/conversionFactor) instead of simply multiplying with the conversion
factor. I still think this obfuscates things more than it helps, but
[at] bska will hopefully want it this way...
this is necessary because tables now must be queried using
EclipseState instead of directly. This implies that EclipseState can
be instantiated in the first place...
TODO (?): allow EclipseState instatiation for decks without a grid.
Using "simple", the Norne deck aborts with an exception.
Note: SPE1 and SPE9 still seem to work fine with this but there might
be small differences so that the reference solutions of the Jenkins
server might need to be updated...
this is required for GCC >= 4.8 to support the 'Q' suffix for floating
point literals (which are used in the quadmath.h header)
In order to prevent compilers which eat the flag but do not support it
from complaining constantly, it is tested for with "-Werror" enabled...
The summary files now always features all wells which ever appear in
the deck in every timestep (even if they are not specified for the
time step). This _should_ fix the crashes when writing Eclipse output
in the Norne deck, but I have no idea if the resulting summary file is
correct. More testing would be thus highly appreciated...
this is basically the dune-grid grid manager for ALUGrid properly
out-sourced into an own module. (it does not require an external
library anymore, so it simplifies the build quite a bit.) Also, the
DUNE-ALUGrid module has quite a few new features and performance
improvements compared to the old code from dune-grid. For details, see
http://users.dune-project.org/projects/dune-alugrid
this is required to make the opm-core build succeed if ERT was build
with -DBUILD_SHARED_LIBS=OFF . (without it, I get errors like
/home/and/src/ert/devel/libert_util/src/thread_pool_posix.c:328: error: undefined reference to 'pthread_create'
instead, use Opm::EclipseState. This requires to pass the PhaseUsage
object to the EclipseWriter, as this one cannot be recovered from
EclipseState (yet?).
copying the EclipseGrid object is required as the final set of active
cells requires knowledge of the grid used by the simulator which is
not available in opm-parser. In turn, this requires to call
EclipseGrid::resetACTNUM() which is non-const.
instead, the wrapper classes now call ERT directly, so it's easy to
see what a given class does. interestingly the amount of additional
code required is neglectible (or even negative).
ERT has been a requirement for opm-parser for a while now and
opm-parser is a prerequisite of opm-core, so ERT is always
available. Thus remove the stub code to avoid bitrot...
Andreas Lauser