Withe this commit the ParserRecord objects are created as needed by the
ParserKeyword; i.e a parserkeyword can in principle be totally without a
record.
For some keywords the number of records is given as the value of an item
in another keyword, for instance the number of records in the EQUIL
keyword is given by NTEQUL item in the EQLDIMS keyword.
If the EQLDIMS keyword is not given in the deck the Parser will consult
the default values of EQLDIMS keyword; i.e. a missing keyword is treated
as all-defaulted.
... 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...)
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...)
This one could only be enable by modifying the source code. If such
debugging output is needed, it should be directly added via std::cout
and removed it before proposing the PR...
note that comment handling is currently a bit too simplistic as stuff
like
FOO
'-- hello' /
won't work. as far as I can see, this is not different from the state
before this patch, though.
this is just the result of
```
find -iname "*.[ch]pp" | xargs sed -i "s/ *$//"
find opm/parser/share/keywords -type f | xargs sed -i "s/ *$//"
```
so if it causes conflicts with other patches, the others should get
priority. The rationale behind this patch is that some people tell
their editor to remove white space which leads to larger than
necessary patches...
i.e., make keywords ALL_UPPERCASE before using them because Eclipse
seems to be case-insensitive (although this is one of its undocumented
features...)
The Norne deck actually exhibits this atrocity in form of the
'fluxnum' keyword in the file 'INCLUDE/PETRO/FLUXNUM_0704.prop'.
I don't know if Eclipse cares about the case of the keywords, but
opm-parser currently does for sure. (If Eclipse turns out to be
case-insensitive, the easiest fix for us is to just make all keywords
ALL_UPPERCASE...)
