If no ParserLog object is provided, stdout is used by default. The
stream can also be used to write to a logfile or it can be omitted
entirely. thanks to [at] joakim-hove for insisting on it...
this basically comes down to adding a few flag keywords but also
requires to add a few E300 fields to TABDIMS...
the grid cannot be instantiated yet as these deck seem to use some
peculiar constructs to specify the grid data. In particular it uses
property modifiers for keywords that specify the grid. (which might be
not allowed by Eclipse but work anyway...) the deck contains something
like
```
GRID
EQUALS
DX 50.0 /
DY 50.0 /
DZ 50.0 /
/
```
which Opm::EclipseGrid can't handle yet because grid properties are only
evaluated after the grid has been instantiated...
unsurprisingly, it's called ParserLog. For now, it is not used very
extensively, but it allows to demingle the log messages from the deck
objects. (i.e., it's possible to pass a const pointer to the deck
object to e.g. EclipseState and one will still get additional log
messages.)
this is useful because DeckKeywords can have almost arbitrary names
(which match a regular expression) which makes it hard to retrieve
additional information about the keyword after it has been created...
The class MULTREGTSCanner internalizes the content of one or several
MULTREGT keywords and can then scan through GridProperty region objects
to find region interfaces as specified in the MULTREGT keyword.
when it comes to PORV, the final pore volumes of logically Cartesian
grids are hard to implement at this abstraction level because pore
volumes may be either specified using the PORO or by the PORV keywords
and both of them are grid properties. This means that to calculate the
pore volumes using the porosity, the porosity grid property must be
already finished when creating PORV. Because of potential interactions
between the PORV and PORO grid properties this is not possible to do
canonically at the grid property initializer stage...
this makes it possible to define more complicated initializers for
grid properties. (needed for example for keywords like ISGU.) This
patch does not introduce them yet, but only adds the necessary
infrastructure.
notes:
- to get around cyclic definitions in template classes, the
EclipseState is changed to a (defaulted) template parameter which
causes the compiler to only look up the class definition at
instantiation time.
- using std::shared_ptr in the property initializers would lead to
cyclic references which would cause memory leaks. To avoid that,
plain old references where used in most places. I think this is
okay as the GridProperty objects should be considered internal to
EclipseState and thus the EclipseState object should live at least
as long as GridProperty objects...
e.g. Eclipse specifies that for PERMX only the topmost layer needs to
be specified, i.e. the following is valid on a 3x3x3 grid
```
PERMX
9*10 /
```
the previous behaviour was to throw.
also, mark if data items have been defaulted, i.e., the item of
```
PERMX
* /
```
will now return true for 'defaultApplied()'.
and also fix a small build bug in these table classes. I don't know
why they have not been also fully dealt with in the recent table code
refactoring...
since tables can be tricky, we now enforce that the compiler bails out
if the user tries to instantiate a table class manually.
Note that a bit of trickery is needed to keep the low-level unit
tests working...
it is _strongly_ encuraged to use the properly named methods to access
the respective columns, but opm-core's current endpoint scaling code
makes it hard to use these...
for some kinds of tables this means linear interpolation for some
columns, constant for other columns and some tables do not allow to
specify default. Since there is no clear rule, this patch involved
checking the reference manual for every single f****** table keyword
plus some guess-work if the reference manual is unclear about
monotonicity and/or defaults.
... and constant interpolation at the fringes. this kind of evaluation
in between sampling point only makes sense for tables where the first
column is strictly monotonic, though.
