order of constructing and obtaining global transmissibilities
was off. replace constructor argument with a setter so it can be
set at the appropriate time.
rather, only set it where we want to use it. this avoids including
eclwellmanager.hh and eclpeacemanwell.hh unnecessarily in
simulator objects (where BlackoilWellModel is used).
make it a template for grid types. this allows using
explicit template instantation and compile this code
only once per grid type, instead of once per simulator object.
|(value-expected)/expected| < tol or |(value-expected)/value| < tol
instead of
|(value-expected)/(value+expected)|
this is how boost::test defines its check
This PR remove the usage of well_control_ from opm-core
and instead uses the control classes for wells and groups
from opm-common.
This PR also removes the usage of the group classes from
opm-core.
This commit switches the 'test_ecl_output' unit test to using the
EclIO::ESmry class from OPM-Common. We add simple alternative
implementations of ecl_get_field_var() and ecl_get_general_var() in
terms of ESmry to avoid rewriting the test code itself.
As class ESmry does currently not support reading non-unified
(separate) summary files (.S000n), we temporarily switch the deck to
using unified output.
- when an episode/report step is over, the next is started by endEpisode()
- the problem does not deal with updating the simulation time anymore
- rename `episodeIdx` in to `reportStepIdx` the 'EclWriter' because
this variable is -- and always has been -- the report step number
used by some parts of `opm-output`'s ECL writing code (the report
step number is equivalent to the episode index plus 1). IMO, the
output and parser code should be made more consistent in regard of
whether it expects 0-based or 1-based indices, but this is a story
for another day.
this is only relevant people who are masochistic enough to go beyond
`-Wall`. (note that at this warning level, there is plenty of noise from
Dune and other upstream dependencies.)
this leads to crashes deeply inside libecl. My cursory hypotheses are
that this test makes the assumption that the output is written
synchronously (it tries to read back the results from disk
immediately) and/or that libecl is not threadsafe.
