this seems to be a compiler bug, but it could be something
else. Anyway, using multiple functions for the tests instead of nested
scopes is probably not the worst idea anyway...
The documentation of this keyword is quite well hidden in the "Other
SUMMARY keywords" section of the Eclipse reference manual, but the
keyword itself seems to be widely used...
the problem was the ALL keyword which caused a naming conflict with
Opm::ParserItemSizeEnum::ALL. I haven't considered the possibility to
break the build by adding a keyword, so sorry for the breakage.
On a more philosophical ground I think it is a bit questionable to
auto-generate test cases at build time because they will automatically
match the keyword definition, whether this definition makes sense or
not...
Previously the control mode was initialized to ORAT; this was later set
to the correct value when parsing the relevant keywords - but in the
case of a SHUT well the control mode was not updated, and we were left
with a well under ORAT control.
For the petrophysical properties PERM? and PORO only the top layer must
be specified, cells further down can be copied from the layer
above. This functionality is implemented with a GridProperty
postprocessor.
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...
