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.
