The data values in a deck item can be in three different states, given
by the DeckValue enum in DeckItem.hpp. The three values are:
SET_IN_DECK : The value has been set explictly in the deck.
DEFAULT : The value was not present in the input deck, but a default
value has been supplied in the configuration and that value
has been set.
NOT_SET : No value has been set for this item; it was not explicitly
set in the deck and also not included in the configuration.
If you ask for DeckItem->value which is in state NOT_SET you will get an
exception. The method setInDeck() can be used to check if a value has
been set explicitly in the deck; the method defaultApplied() will check
if a default value has been applied.
Observe that the system for handling defaults is not really well suited
for multi valued data items, as it is only a scalar state variable. In
the case of multi valued data items both defaultApplied() and
setInDeck() might return true.
this is required in situations where double grid properties depend on
the values of integer (i.e, *NUM) ones which appear later in the
deck. Example:
```
PROPS
SWU
* /
REGIONS
SATNUM
*2 /
```
the default value of the SWU keyword depends on the value of the
SATNUM property which only gets defined later in the deck. an
alternative to the approach of this patch would be to process the
grid properties of the REGIONS section before the others. I'm a bit
indifferent which approach is better...
this comes with a minor API change as well, as the FaultCollection
class did not use the Cartesian size of the grid at all, so I decided
to remove the attributes and the arguments to the constructor...
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.
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.
