"BHP" stands for "bottom hole pressure" so it sounded logical that
"THP" is an acronym for "top hole pressure". It isn't but the quantity
in question is still the pressure which is seen at the top of the
well's bore hole...
the ones based on Splines are better in principle, but they cause
havoc if two saturations are very close together with the slope of the
values off. this happens e.g. in SWOF in my version of SPE1...
this makes eWoms match autodiff and Eclipse for SPE-1 if the injector
is disabled. with the injector it gets quite a bit closer, but it does
not yet match. (this is probably not a problem with the wells as
autodiff and eWoms agree that the maximum amount of gas should be
injected all the time and these rates are the same...)
ECLiPSE and opm-autodiff seem to be in that range of accuracy, too. At
least the number of Newton iterations per time step now matches that
of autodiff quite well...
this helps to keep the core blackoil model code lean and mean and it
is also less confusing for newbies because the ECL blackoil simulator
is not a "test" anymore.
in case somebody wonders, "ebos" stands for "&eWoms &Black-&Oil
&Simulator". I picked this name because it is short, a syllable, has
not been taken by anything else (as far as I know) and "descriptive"
names are rare for programs anyway: everyone who does not yet know
about 'git' or 'emacs' and tells me that based on their names they
must be a source-code managment system and an editor gets a crate of
beer sponsored by me!
This code is required in the first place because opm-material always
specifies all parameters in terms of the wetting saturations while the
gas is the non-wetting phase in a gas-oil system.
it is just deactivated using an always-false condition so it does not
bitrot and can be re-activated quickly. I did not want to completely
remove this code because it is useful for debugging purposes, but for
regular use, it should have been superseeded by the ECL summary output
stuff...
most importantly, the pressure update by the linear system of
equations is now considered to be mainly a hint for the linear
solver. the peaceman well class thus always calculates the bottom hole
pressure which exactly corresponds to a given state of the grid before
each iteration. (this is because calculating the BHP is really fast
compared to requireing more non-linear iterations.)
also, the well residual is now used for all calculations and has been
simplified a bit.
finally, the wells class now provides more methods which allow to
query its internal state (i.e., surface and reservoir rates, BHP/THP,
rate targets, etc.)
this does not disrupt the block nature of the linearized matrix
(i.e. Dune::BCRSMatrix is still used), but if the number of auxiliary
equations is smaller than that of the "main" discretization, the
superfluous equations are padded. if the number of additional
equations are larger than that of the equation, additional DOFs are
added.
the biggest change is that it is now based on a new approach: the well
model now always calculates the bottom hole pressure for the full well
when asked for a source term. This change makes it possible to
implement cross flow within wells properly and should also make the
well model physically correct.
Also, the well model now uses the connection transmissibility factor
which makes it possible to use this quantity if it is specified by the
deck...
so far, it is only fully implemented for the VTK format. Because Dune
has some deficits in its VTK support for tensors, these quantities are
treated as multiple column vectors. Wake me up when I am older...
this is done by only calculating intensive quantities for elements
which actually are pierced by wells. on SPE1 this lead to a
performance improvement of about 2% on my machine. (3.50 vs 3.57
seconds.)
this time without looping over the whole grid. the limited rates are
only losely coupled to be the ones used by the actual source terms, so
if the rate limiting code is changed the statistics gathering piece
must also be adapted. This is kind-of sub-optimal because it requires
some code duplication, but the alternative would be _much_ less
performant...
during debugging this was used to make sure that the rate limits are
correct. the issue is that this is slow if many wells are involved
because it uses a full iteration over the grid for each well to
calculate these rates...
this means that all code which could potentially throw an exception is
moved to this method(). (In particular FluidSystem::init() proved
troublesome in the past.) Besides avoiding segmentation the faults
which stem from exceptions thrown in constructors, this also has the
advantage that simulations which spend a noticable amount of time to
initialize stop at the "correct" place, i.e. after the "Finish init of
the problem" message was printed by the simulator...
this regressed after time step index of the initial solution was
changed from 0 (actually, this was also 0 for the first time step...)
to -1 in b30af664.
"intensive" means that the value of these quantities at a given
spatial location does not depend on any value of the neighboring
intensive quantities. In contrast, "extensive" quantities depend in
the intensive quantities of the environment of the spatial location.
this change is necessary is because the previous nomenclature was very
specific to finite volume discretizations, but the models themselves
were already rather generic. (i.e., "volume variables" are the
intensive quantities of finite volume methods and "flux variables"
are the extensive ones.)
