this is similar to the mechanism for well models: the API is defined
here, but can be overloaded by downstream modules. In contrast to the
well model where the default class follows a simplistic approach the
default class for aquifiers does nothing, i.e., the actual
implemenentation must be provided by downstream.
before this patch, the parameter was registered by the problem but not
used there. Since this is quite confusing, let's move registration to
where the parameter is actually used, i.e., the vanguard.
i.e., complain when detecting foo=bar positional parameters. this is
not a bullet-proof solution because it will not work if the deck file
name contains an equals character. Anyway, it's better than before
IMO.
all disc output, i.e. VTK, restart files, ECL and -- in the future --
logfiles, goes to that directory. before this, only the ECL output
could be directed to a different than the current working directory
and the parameter for this was called "EclOutputDir".
note that the Dune VTK writing infrastructure makes it harder than it
needs to be: suddenly Dune::VTKWriter::write() does not work in
parallel anymore, but Dune::VTKWriter::pwrite() must be called with
the right arguments.
previously, the exact behaviour was dependent on wheter the
--ecl-deck-file-name parameter was defined or not. now the positional
parameter is hopefully an exact alias for the value of --ecl-deck-file-name.
the purpose is to make it exceedingly clear that ebos is not developed
by the ECL group who started ECLIPSE which is an backcronym for
"ECL's Implicit Program for Simulation Engineering" and ECL stands for
"Exploration Consultants Limited" which is now a division of
Schlumberger Limited.
thanks to [at]atgeirr for pushing this.
there are about a trillion places within ebos where the availability
of the ECL I/O routines is hardcoded, so it does not make sense to
pretent that the EclWriter can be useful without them.
(in fact, ebos is deactivated at build system level if the ECL I/O
routines have not been detected.)
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.)
i.e., the ECL restart files are not necessarily updated after each
report step, but only each N-th (where N is the number specified by
the EclOutputInterval parameter). if this value is set to something
smaller than zero, the value which is computed by the EclipseState
object is used.
further, this cleans up the code of the parameter system and the
startup routines a bit and finally, it adds positional parameters
support to ebos as well as brief descriptions to ebos and the lens
problem.
this is required because temperature needs to be always specified. in
the case of isothermal simulations, the temperature is assumed to be
the initial one, i.e., freeing up the initial fluid states also makes
the temperature undefined.
I suspect that the reason why this did not lead to crashes is that for
isothermal `BlackOilFluidState` objects, the temperature is stored in
a static member variable.
thanks to at [at]bska for catching this issue.
with this, it is possible do define fluxes of conservation quantities
over the domain boundaries by specifying the thermodynamic state on
the boundary when using the black-oil model. The main motivation is
are thermal fluxes which are required to maintain geothermal
temperature gradients over time.
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.
IMO the term "vanguard" expresses better what these classes are
supposed to do: level the ground for the cavalry. Normally this simply
means to create and distribute a grid object, but it can become quite
a bit more complicated, as exemplified by the vanguard classes of
ebos..
the eWoms file naming convention should probably be changed to the one
of the remaining OPM modules, but this is quite a bit of work and IMO
it is more important to be consistent within the module.
instead, let's bit the bullet and add the few lines required for
regula-falsi-Pegasus method whenever the old RegulaFalsi class was
used. note that this leads to slightly different results for the
SPE5CASE1 flow test. I suspect that the old solvers behave in
unexpected ways, though...
Note that because the inverted functions are usually piecewise linear,
inversion can be done in a much smarter way.
this only deals with the easy things, i.e. UgGridHelpers::numCells()
and UgGridHelpers::dimensions(). a more thorough cleanup is needed in
the future to make ebos work with grids other than Dune::CpGrid again.
now, all the beauty of that part of the code can be admired in
initStateEquil.hpp.
During this exercise, I stumbled over some serious code-quality issues
like a different order of the template arguments for the declaration
and the definition, mismatching argument names and no forward
definition of some functions. besides this, some functions were
already defined in the non-_impl.hpp file and EquilibrationHelpers.hpp
used that approach from the outset.
this just moves the hydrostatic equilibrium code from its historc
location at opm/core to ebos/equil and adds minimal changes to make it
compile. this allows to clean up that code without disturbing the
legacy simulators.
since the unit code within opm-parser is now a drop-in replacement,
this simplifies things and make them less error-prone.
unfortunately, this requires quite a few PRs. (most are pretty
trivial, though.)
the purpose of this is to get a more defined behaviour when doing the
gravity correction/upstream cell determination in the flux term.
I consider this to be just a kludge, so if anyone has a better idea of
what the composition for the non-existing gas and oil phases is,
please tell me. (note that generic compositional models do not exhibit
this issue because the composition of all fluids is always fully
defined because each component is assumed to dissolve in every phase.)
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
the largest change is that all classes below opm/core/props/pvt take
the PVT region index as an argument, the higher-level ones (i.e.,
BlackoilProps*) take cell indices.
depending on the grid implementation, the grid view / grid part object
does not necessarily follow the change. For some reason, the grid part
still does not work in the parallel case (tested with dune-fem 2.4),
but that seems to be an issue on the dune-fem side.
This reverts commit c873e8c92da389bc1d6bc4ed2a5241faddfa7630.
since OPM/opm-simulators#1287 has been merged there are no "in tree"
upstreams which use that mechanism anymore.
this now works with the unmodified master version of flow from
opm-simulators. we take the liberty to emit a deprecation warning,
though. this complicates things quite a bit.
This gets rid of some special-purpose code in generic places (i.e. the
`SimulatorParameter` class) and no special hacks to the property and
parameter system are required anymore.
Andreas Lauser