it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
if PETSc is not available, the .cpp file will compile fine because it
will be reduced to be empty, but trying to include
LinearSolverPetsc.hpp in this case will result in an error.
This is quite a hack: Even though energy is not a "phase" and it is
also not considered in MaxNumPhases and pu.num_phases because this
would break a lot of assumptions in old code, it is nevertheless
assigned an "canonical index" that can be translated "active index"
via PhaseUsage::phase_pos[]. This awkwardness is needed because much
of the legacy OPM code conflates the concepts of "fluid phase" and
"conserved quantity" and fixing that issue would basically mean an
almost complete rewrite of much of the legacy code. That said, the
same statement applies to polymer and solvent, but these are currently
handled as even more second-class citizens because they are not even
given a canonical index and also cannot be translated into an active
one.
this used to provide autotools compatibility, but it has not been working for a while. Thus it is IMO better to remove it in order not to mislead people.
this information is already part of the EclipseState. The reason why
this should IMO be avoided is that this enforces an implementation
(ordering of the permeability matrices) the simulator on the well
model. If this needs to be done for performance reasons, IMO it would
be smarter to pass an array of matrices, instead of passing a raw
array of doubles. I doubt that this is necessary, though: completing
the full Norne deck takes about 0.25 seconds longer on my machine,
that's substantially less than 0.1% of the total runtime.
in order to avoid code duplication, the permeability extraction
function of the RockFromDeck class is now made a public static
function and used as an implementation detail of the WellsManager.
finally, the permfield_valid_ attribute is removed from the
RockFromDeck class because this data was unused and not accessible via
the class' public API.
this fixes some valgrind errors while doing the twophase capability
for flow_ebos: In all previously tested cases, these errors were
probably non-fatal because the memory illegally accessed here is
likely to be allocated (but after this function was finished it
contained garbage).
note that I'm not completely sure if this patch is semantically
correct, so I'd appreciate some input who understands it. (what is
"z"?)
since the unit code within opm-parser is now a drop-in replacement,
this simplifies things and make them less error-prone.
unfortunately, this requires quite a few PRs. (most are pretty
trivial, though.)
the purpose of this is to get a more defined behaviour when doing the
gravity correction/upstream cell determination in the flux term.
I consider this to be just a kludge, so if anyone has a better idea of
what the composition for the non-existing gas and oil phases is,
please tell me. (note that generic compositional models do not exhibit
this issue because the composition of all fluids is always fully
defined because each component is assumed to dissolve in every phase.)
since
f(x) = 1 + 0.5*g(x)*g(x)
the derivative is
f'(x) = 0 + 2*0.5*g(x) * g'(x) = g(x)*g'(x)
note that the previous incorrect values do not affect the quality of
the obtained results (if the tolerance of the non-linear solver is
chosen to be small enough), but it may have deteriorated convergence
rates.
the typo was caused the surface density of the oil phase to be used
instead of the one of gas. This caused the density to be off by a
factor of typically about 900.
using saturated FVFs does not change much, but it does not hurt
because it is also done that way in the simulator.
This makes the defaults for the threshold pressures reasonable again,
but for some reason they are not exactly the same as in the old
implementation. (although the differences are very tolerable.)
On the question why only "Model 2" is affected by this: the other
decks don't use threshold pressures (SPE-X) or do not default any
values (Norne).
the dissolution factors used for the viscosities were always zero so
far. this was not discovered earlier because flow is completely
unaffected by this since the only place where this class is used in
flow is the equilibration code and the equilibration code does not
need phase viscosities.
thanks to @atgeirr for finding this.
the opm-material classes are the ones which are now used by
opm-autodiff and this patch makes it much easier to keep the opm-core
and opm-autodiff results consistent. Also, the opm-material classes
seem to be a bit faster than the opm-core ones (see
https://github.com/OPM/opm-autodiff/pull/576)
I ran the usual array of tests with `flow`: SPE1, SPE3, SPE9 and Norne
all produce the same results at the identical runtime (modulo noise)
and also "Model 2" seems to work.
While the patch is quite trivial (some forgotten 'const'), the havoc
was caused because I usually configure my modules with --disable-tests
(to get much better turn-around times when switching all modules from
debug to optimization flags) and the usual way to force them to
compile ('make test-suite') does not work for opm-core...
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.)
Andreas Lauser