reads tracer input from deck, solves tracer equation fully implicit as a post processing step in endTimeStep
tested on a simple modified SPE1CASE1 deck and compared with eclipse
TODO: restart and parallel
this allows to assemble the Jacobian matrices directly into the native
format expected by linear solver. So far, only backends using
Dune::BCRSMatrix are provided, but there are work-in-progress patches
for dune-fem, vienna-CL and PETSc backends.
IMO the simulator should not be in the business of managing low-level
parser objects in the first place, because that's what EclipseState is
supposed to do?!
anyway, since these objects are not needed to decide which simulator
to use, they are now always managed internally by the vanguard, i.e.,
setExternalDeck() does not take them anymore.
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.)