this is required by the Norne deck. the EQLOPTS keyword seems weird,
though, because its records seem to have a variable number of items...
for most of these the RM says that if nothing is specified, a value of
another item should be used. some items even have legitimate
defaults, but they are only mentioned in the prose of the RM's item
description. (e.g.the wetting_phase_flag item of the EHYSTR keyword...)
The getKeyword() method will autocreate and initialize a keyword if you
ask for one which is supported, but has not yet been accessed. The new
getInitializedkeyword() method will raise an exception if the keyword
has not already been initialized.
... but throw later when trying to access the data of the item in
question.
Note that this was demanded by [at] joakim-hove and that I do not want
to be held responsible for any issues which are caused by this
approach. (read: please direct your barks to Joakim if you fell on
your nose because of this...)
for many of them the RM says "default is undefined" but that I've come
to the conclusion that this doesn't mean that no default could be
applied, but that the simulator is allowed to screw up if the values
of them are accessed. (Note that in this sense this change is no
change from the current situation, but makes the screw-up more
explicit.)
In particular, note the GRIDUNIT keyword which had some serious JSON
syntax errors in it but so far the unit tests worked anyway for some
reason...
this can be used to directly specify transmissibilities for
NNCs. Note that this keyword is quite a mess for everything after
the mandatory items according to the documentation.
this is required because Eclipse is inconsistent when specifying
transmissiblities: the only difference between transmissibilities in
metric and field units is that the pressures are in bars instead of
PSI, i.e. the numerator for metric units is still given in centi-Poise
times bbl. This makes it impossible to specify the transmissibilities
in terms of their constituting bits...
mostly, include the keyword names, so that the user can fix these
errors without using gdb. (Not that I mind gdb, but I have been told
that gdb is a big no-no. ;)
(this patch also fixes a few typos...)
The region multipliers are no longer added to the cartesian logical
MULT[XYZ] structure. Instead a new method
getRegionMultiplier(globalIndex1, globalIndex2,FaceDir) is added that
return the multiplier between globalIndex1 cell and globalIndex2 cell.
The face direction is added to support directional dependent MULTREGT
input. This implementation of MULTREGT also supports restricting the
multipliers to only apply for NNC or NONNNC.
