This fixes further occurences of DUNE_HAS_FASTAMG that were
missed in pull request #530.
Previously we relied on the define DUNE_HAS_FAST_AMG to detect
whether these preconditioners are available. This define is only
available in the 2.2 release with cmake support. Therfore we now
addtionally test whether we are using dune-istl 2.3 or newer.
This means that EclipseKeyword now never processes the data it
gets. Instead the data must be explicitly preprocessed by the calling
site using the new auxiliary functions "convertUnit()",
"extractFromStriped()", etc. This approach needs a few additional
temporary copies of the data, but given the facts that readability of
this code is much better using this approach, and that EclipseWriter
is neither a performance- nor a memory critical codepath, I don't care
too much about those temporary arrays...
and throw an exception if "simple" is encountered...
According to Ove, gwseg should be used, because "gwseg is the model
relevant to the norne case - i.e the model eclipse uses.
The fix for the simple model has to wait for a refac of the satfunc
complex."
Previously we relied on the define DUNE_HAS_FAST_AMG to detect
whether these preconditioners are available. This define is only
available in the 2.2 release with cmake support. Therfore we now
addtionally test whether we are using dune-isl 2.3 or newer.
Patch 31c09aed was erroneous as it was trying to assing a
SaturationPropsFromDeck<SatFuncSimpleNonuniform> to a
SaturationPropsFromDeck<SatFuncSimpleUniform> in the constructor
taking the new parser. This patch fixes this.
that is one of the more subtle differences between the old and the
new parsers. now, valgrind does not seem to complain anymore, so everything
should be All Right (TM) ;)
- the output=true|false parameter gets respected now
- if output is "true", it is checked that the value of the
"output_dir" parameter is a directory (although I did not find an
easy way to check whether it is writable short of writing a file to
it.)
- the "output_interval" parameter gets respected as well
- the index of a written timestep is now independent of the time step
index of the simulation: the initial solution is always 0, the first
result written to disk is always 1 and so on... (i.e., it does not
matter anymore how many steps the simulator needed between two writes)
these changes have been proposed by @atgeirr. Thanks!
The mentioned commit was applied before the merge of
opm-parser-integrate and therefore the changes did not carry over
to the code that uses the new parser. This code mimics the
changed behaviour for the new parser.
Closes issue #516
because the name "currentTime()" can be mistaken for the point in
real-life time at which the simulation is run (e.g. March 11, 2014,
15:07:45.123), the _point_ in time which the simulator timer currently
represents (e.g. Jun 5, 1985, 02:33:12.345) instead of the simulator
time in seconds which elapsed since the START date
(e.g. 52633.345 s).
this rename may lead to some fallout in other modules. I'll
fix them after this PR has been merged...
Instead of making well rates zero for wells that are not controlled by
surface volume, we initialize them to a small value with the correct
sign (positive for injectors, negative for producers).
After transitioning to use the new parser, the SinglePvtDead class was never
used even when the 'samples' argument used to control usage was zero or negative.
The resulting construction of SinglePvtDeadSpline objects was then failing.
This change adds a new constructor to SinglePvtDead, and restores the ability
to control spline usage with the samples argument.
Since SimulatorTimer is a fairly shallow shim if using the TimeMap, it
can also be removed relatively easily. Having said this, that would
trigger _many_ changes in _a lot_ of places and I'm not motivated at
all to fight that battle as long as the old parser needs to be
supported. I thus decided that the best way is to add a "wrapper mode"
to SimulationTimer...
This includes relative permeability and capillary pressure functions.
The default has been to make a monotone spline from the given table
values and use a fine, uniform sampling of that. Now the default
is to use the tables as-is. It is still possible to use the spline
approach. For example in the class BlackoilPropertiesFromDeck one
may pass nonzero values for the 'pvt_tab_size' and 'sat_tab_size'
parameters, corresponding to how fine the spline will be sampled.
