most of these issues are fallout from the conversion of the spline
class from a moments (second derivative) based approach to hermite
base functions:
- the second and third derivatives where incorrect, and the third
derivative was not available in the public interface.
- The unit test did not check the derivatives
- The coefficients for the monomial basis were off by the factors
stemming from the derivatives
- The intersectIntervall_() method used std::max() instead of
std::min() at one place and still added the base offset for the x
values as indicated by Stoer
Currently, it still writes out whatever conservation quantity which is
used by the solver (which is probably the mass of the oil/gas
mixture). TODO: convert these solver rates to "pure oil volume without
gas at the surface" and to "gas volume at the surface" rates.
thanks again to Joakim Hove for the pointers where to start kicking!
most code was shamelessly ripped from opm-core's EclipseGridParser,
but there are some additions (e.g. grids specified using the D[XYZ]V
Eclipse keywords can be used).
The code is located inside the new class "BlackoilEclipseOutputWriter"
(should probably renamed) and hooked up in
SimulatorFullyImplicitBlackoil and sim_fibo_ad.cc.
Also be aware that, to make this code work properly, the newest master
version of ERT is required (i.e. one which includes commit
5e4e9661720). In this context, I would like to thank Joakim Hove for
his support!
Since there are a few new APIs and features, but no major changes,
it seems proper to move from 1.0 to 1.1, even though strict
backward compatibility cannot be expected.
Label bumped to 2013.10.
A vector can of course never contain a negative number of elements, so
naturally size() returns size_t instead of a regular int. This costs us
a warning unless we also change the loop counter (since it is only used
to index that vector).
The 'comp_term' is supposed to be a total divergence term, which is supposed
to be zero for incompressible flow. It was added for improved robustness in
stagnant areas, but as implemented it would not be computed properly for
oil injection scenarios, due to the convention for two-phase transport
source terms (positive terms are inflow of first phase [water], negative
terms are total outflow).
The WellsManager class handles INJECTORS by assigning a phase
distribution (W->ctrls[i]->distr) that coincides with the injected
fluid for the corresponding well (e.g., {1,0,0} for WATER injectors in
a three-phase WATER/OIL/GAS simulation). This, however, meshes poorly
with the restriction that all phase components must be ONE in the case
of wells constrained by total reservoir volume flow targets (RESV)
that was introduced in commit b7d1634.
This change-set limits the restriction on phase distributions to
PRODUCERs only and is a tentative solution to GitHub PR #360.
This should fix the common case where the curve is non-constant within
an intervall. I'm not really sure whether it's correct in all corner
cases, though.
this fixes the eWoms test case for the blackoil model which failed in
debug mode due to some asserts incorrectly triggering...
Otherwise the compiler will probably give us a warning that these
pragmas are unknown. By default that warning is disabled with our
own build system, but we also want to be able to link to our library
without incorporating the entire build system too.
To avoid deprecation warnings the number of smoothing steps was passed
through the Criterion instead of directly to the constructor in commit
a7f32b934b.
However, due to an insufficient test matrix this was not tested using
the fast AMG variant of DUNE so it breaks the builds if
`-DHAS_DUNE_FAST_AMG` is defined.
This change should apply the same type of change to this branch as for
the others. The number of smoothing steps is put into a constant to
avoid the magic number 1 to appear in too many places (although I am
not sure the number for pre- and post-smoothing always should be the
same).
