the reason why this is needed now probably is because
std::is_convertible<Scalar, Evaluation> is false. While strictly
speaking, scalars can be converted to Evaluations by assuming them to
be evaluations of the constant function, this patch is IMO beneficial
anyway because it makes such conversions more visible.
the in-file lists of authors has been removed in favor of a global
list of authors in the LICENSE file. this is done because (a)
maintaining a list of authors at the beginning of a file is a major
pain in the a**, (b) 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 removing
the lists...)
the only exception of this is the eWoms fork of dune-istl's solvers.hh
file. This is beneficial because the authors of that file do not
appear in the global list. Further, carrying the fork of that file is
required because we would like to use a reasonable convergence
criterion for the linear solver. (the solvers from dune-istl do
neither support user-defined convergence criteria not do the
developers want support for it. (my patch was rejected a few years
ago.))
this has slowly become a hassle to support (i.e., it cluttered the
source with many #if's and in particularly the code was not tested
with Dune 2.2 on a regular basis). Also, Dune 2.3 has been out since
more than two years, so IMO it is not asked too much to ask people who
want to use the latest and greatest version of ewoms to upgrade their
Dune.
... instead of the EclipseGrid object returned by opm-parser. This is
required because the nice grids of dune-cornerpoint sometimes decide
to deactivate a grid cell on their own (e.g. because of the MINPV or
the PINCH keywords).
the intention is to abort more quickly if a time step is not going to
succeed and also to prevent the time step size to grow too quickly
again after it was reduced. Note that these parameters this patch only
changes the defaults, i.e., these paramters can still be specified at
runtime.
the only non-cosmetic change is the reduction of the magnitude of the
tubing head pressure from 10^100 to 10^30. this does not matter
normally, but if single precision floating point values are used
10^100 cannot be represented by such variables (and also 10^30 is
large enough by a fair margin: I doubt that one ever wants to simulate
the conditions in the core of a star using this code.)
before this, a zero matrix was produced on the main diagonal which
(rightfully) caused the linear solver to bail out. Now, the linearized
equation is still rubbish, but it is not singular anymore and the
result for shut wells is not used anywhere in the first place...
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).
