for this, an Section::isDeckValid() method is introduced which checks
that a given deck is valid when it comes to the sections
(i.e. presence of mandatory sections and section ordering)
We now do not require the sections to be correctly ordered and the
presence of the mandatory sections since even the unit tests did not
always specify all mandatory sections, which lead to a section
containing the rest of the deck if one of the expected next sections
was not specified.
also it seems like the DeckKeyword::getDeckIndex() does not correctly
work in some situations which lead
assert(deck->getKeyword(i)->name() == startKeyword);
to fail in the Section::populateKeywords() method. now the deck is
always sequentially traversed to find the position of a section's
start keyword. (This is necessary anyway if one wants to make sure
that the deck does not specify the same section more than once, a
feature which this patch also adds.)
The purpose of this flag is to keep track of whether a keyword is
supposed to have only one element, i.e. scalar, or several. The
defaultApplied method only makes sense in the case of scalar items, this
method will now throw if it is called on a non-scalar item.
which is like getString() but with the leading and trailing white
space removed. It is intended for names which seem to not care about
such white space in Eclipse.
this is meant for those nasty keywords where the dimension of an entry
depends on a user-defined value of some field of a (potentially
different) keyword. One example for this are the surface rates of the
produced fluids for the .CON(INJ|PROD).* keywords which exhibit
different units depending on whether the user choses to control for
the surface gas or the liquid rate.
the approach taken in this patch is to convert all numbers to NaN if
the unit is queried in SI (via item->getSIDouble()). It might be more
desireable to throw an exception in this case, but this approach would
be more elaborate and NaNs should be quickly noticeable by the users
of this code.
I tried to adapt all implemented keywords, but it's quite likely that
I missed some...
This resulted in _quadratic_ complexity if data points where retrieved
one-by-one. For the Norne case, this had the consequence that
retrieving the data for ZCORN (-> about 1M data points) took hours...
the fact that data is lazily converted to SI units should not be
relevant for the caller. This requires to decorate the array for SI
units in the DoubleItem as mutable, though...
