the mistake was that I assumed that this was specified by the ROCKTAB
keyword; It is not! (It's specified via PVTNUM or SATNUM depending on
the value of the third item of the ROCKOPTS keyword. for now, let's
only use the PVTNUM.)
the missing piece was determining if the wells have changed between
report steps. This patch adds a simple way to determine this, but it
relies on low-level properties of opm-parser it does not
guarantee. (concretely, these details are that the same well objects
are returned in the same order if nothing changes. Since IMO this is a
pretty reasonable assumption, we use this approach instead of a more
complicated one until opm-parser provides a "change determination API"
for wells...)
note that this patch may increase the number of iterations required
for the simulation because the linear system of equations which is
solved in the first iteration of a time step actually corresponds to
the second to last solution of the previous time step. This means that
that linearization recycling usually only works well if the tolerance
of the Newton-Raphson solver is "sufficiently" low. ("sufficiently"
means that the linearization errors made due to using the "wrong"
solution for the first iteration can be neglected compared to the
differences because of the change of the solution in this iteration.)
therefore, use this feature at your own risk...
it often causes quite substantial headaches but does unfortunately not
normally lead to a substantial speedup. (at least not in its current
incarnation.)
in particular, the ECL schedule is now used to determine the episode
length on restart. this code is still quite shaky IMO, although it
seems to work for now.
this means eWoms restart files (*.ers), not Eclipse (*.UNRST) ones. by
default, the restart file writing interval is once every 2^24-1
timesteps, i.e. it is effectively disabled. The interval is settable
using the '--restart-writing-interval=$N" command line parameter,
though.
say 99.95% of all time: premature optimization is the root of all
evil.
in this case it turned out that iterating over a std::unordered_map is
very slow and that this is a quite common operation in
ebos. Fortunately the fix for this problem is very simple: use the
tree-based std::map instead of the hash function based
std::unordered_map.
on SPE9 this yielded a performance improvement of about 10% on my
machine...
strangely enough, this leads to slightly worse convergence for SPE9 on
my machine (19.0 vs. 16.8 seconds runtime). Nevertheless this is
definitely "more correct" from a physical point of view.
This reverts commit 3e247b059f20b1d04f47bd832719a99df8b9ac26. After a
more thorough investigation, the cannonical name of these quantities
turned out to be "* formation volume factor"...
this makes it possible to compare ECL restart and summary files
produced by ebos directly with the ones stemming from Eclips. (But be
aware that VTK output files from ebos are still all-SI!)
in particular, the partial relinearization seems to cause some _very_
weird effects. (the results differ very significantly for SPE1.) I
still have to investigate why, but I suspect that this is caused by
the fluid system being not continuously differentiable (it's piecewise
linear).
also, do not touch the region index in scalar assignments for black
oil primary variable objects. the first change is required by because
assignMassConservative() accesses the region index and the second
because scalar assignments should not modify the PVT region of the
primary variables. found by clang's ASAN.
