the RE used is specified via the "deck_name_regex" in the JSON file of
the respective keyword. A deck name is assumed to match a given parser
internal keyword if the deck name is valid and if it is either in the
list specified by the "deck_names" entry or if it matches the regular
expression.
This functionality is useful to implement the well probes for the
tracers as well as replacing the current "wild card keyword"
implementation which only allows a star as a suffix.
this is required for regex-matching keywords. Once GCC 4.9 is the
minimum compiler version to be supported, this can be dropped in favor
of std::regex ...
Whoever came up with that keyword deserves a spanking because its
semantics are adapting thickness of the grid layers using the rock
properties without modifying the grid (and thus the output is not
showing what is actually used). As I understood that whole affair,
this is also done incorrectly, because the flow is not distorted in
depth direction but this the permeability should be divided by the NTG
values as the fluids seep through the thinner layers more quickly...
Anyway, we have to implement it, so here we go.
before this, the variants with the trailing minus were just silently
ignored, and even if they were not, the code generator would have
produced illegal code, because the keyword name is used for a C++
variable there, i.e. the names needed to be valid names in the C++
sense. "Happily", these the former bug canceled the latter, so the
build went through...
now, there is only one internal keyword called "MULT_XYZ" which
matches on all possible variants which are allowed in a deck. The
mechanism used is a deck name list...
These are all keywords which are used by the Norne deck within some
property modifiers plus all variants of these. (sans the variants for
radial grids which are completely pointless IMO.) The chances that
keywords which have not been added yet can also be used are very close
to 100%, though.
Note that the default values for these keywords are currently
incorrect as the Eclipse RM states that the values must be looked up
in their corresponding table if the keyword is left unspecified (see
e.g. the documentation SWU). This probably means that we need to
implement "ghosty" keywords which magically appear if they have not
been explicitly specified or maybe we should only provide them in
EclipseState to be able to do the context dependent table look-up
"vodoo"...
this uses a small amount of template magic, to automatically change
the API of the GridProperty class depending on wheter it is
instantiated for double or for int.
there was a "typename" outside of a template, but because the
syntactic sugar is created by the Boost unit testing framework, it was
not clear wheter it was a template or not.
Also, some harmless warnings have been fixed. These only appeared
because a few variables have recently been converted from int to
size_t...
