to my defense I can say that the Schedule::events() API was not
present in opm-parser when the EclWellManager needed this. (I think it
wasn't available back then, maybe I just was not aware of it.)
once again it was broken by a change in opm-parser for which the
original authors not care to fix the mess they caused in ewoms. this
time the culprit was OPM/opm-parser#677.
this is required because that property is "drive-by created" when
initializing the grid and the code in opm-autodiff ignores it. (and is
slightly inconsistent with what opm-parser does...)
only if hysteresis is enabled. This is necessary because after the
hysteresis update the same primary variables will result in a (usually
only slightly) different thermodynamic state than before the update.
the stencil can now be updated only for the primary degrees of freedom
and output modules can specify that they do not need extensive
quantities (which allows to speed up the writing code if none require
them.)
Also, all loops over the grid are now threaded (or rather, are
supposed to be), so openMP should be better utilized during the
linearization stage.
the change for the inverse formation volume factors (instead of the
FVFs) is needed to keep the build happy, using the new
getRv_()/getRs_() infrastructure might slightly improve
performance. (the emphasis is *slightly* because it only changes
something if BlackOilFluidState is used for initialization and
initialization is not time critical in the first place.)
all processes must be aborted, whilst the error message should only be
printed once. Also, calling std::exit(1) results in "nicer" output (at
least on openMPI) because mpirun does not try to print a stack trace
for every process.
now, we abort at run time if the user tries to use with Dune::CpGrid
in parallel simulations. The advantages are that during build there
will be no warning anymore (before the warning was printed at compile
time regardless of which grid was actually chosen), and that such
simulations cannot be started with more than a single process (before
they started just fine, but they did not work properly).
This code should be removed as soon as "Dune::CpGrid" gets its act
together and fixes the bug in the loadBalance() method.
this is because the loadBalance() method of Dune::CpGrid is seriously
broken at the moment: it throws away elements even in sequential mode
for some more relevant grids. ("more relevant" == "Norne". Norne is is
buggy itself because it features two completely disjoint parts.)
but it is even worse than that: if the bug mentioned above bites,
Dune::CpGrid cannot even agree for itself how many elements it has
which causes the CartesianIndexMapper to segfault.
at least, they compile as far as eWoms is concerned. Some external
libraries (in particular everything which uses SuperLU) still have
issues.
Also, there seem to be issues with the precision that is achievable
by the Newton method when using float.
an interesting side effect is that the Newton convergence output is
only defined if the VTK output is enabled.
Also, this patch could be implemented more efficiently by retrieving
the EnableVtkOutput only once per output module (instead of once per
element).
i.e., there is now a base class for the EclGridManagers and one class
for each type of grid (Dune::ALUGrid, Dune::PolyhedralGrid and
Dune::CpGrid). Selecting the concrete grid type is now done by
deriving the EclProblem's type tag from the type tag of the respective
grid manager.
that's because its applicability for non-cornerpoint grids is _very_
limited. Also the class is renamed to 'AluCartesianIndexMapper'
(because its purpose is to be used in conjunction with dune-alugrid)
and the namespace is changed from 'Dune' to 'Ewoms'.
operator>=() is available for Opm::Evaluation, and its efficiency is
the same as explicitly comparing the value. Let's thus remove this to
reduce optical noise.
i.e., calculate the pressure which the exterior cell of a face would
exhibit at the depth of the interior one (instead of bringing both to
the depth of the face).
because the average fluid density is used, there should not be a
difference because of this.
for large problems with many wells the performance impact of this is
probably even measureable.
Also, this patch makes it possible to access the well manager outside
of the problem. In the normal case, this should be rarely needed, but
it can come in handy for debugging purposes.
