With this commit the generation of built in keywords is completely
changed. The most important changes include:
1) We have autogenerated a class for each keyword in the new
ParserKeywords { ... } namespace.
2) The autogenerated classes derive from ParserKeyword, and the
default constructor will build of a fully initialized
ParserKeyword instance, i.e. the keyword used to parse the EQUIL
keyword can be instantiated as simple as:
ParserKeywords::EQUIL kw;
3) The generated keywords have built in static constants for keyword
and item names, and item default values. That way it should be
possible for the compiler to catch trivial errors like trying to
access the keyword "PoRO"; also the the access to default values
means that properties can be initialized without actually
insantiating a DeckKeyword.
4) Two new classes Generator/KeywordLoader and
Generator/KeywordGenerator have been created, with the help of
these classes the keyword generation code is significantly
simplified.
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.
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 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...)
which is more what the method does because the keyword can still
contain an error in its data which would make it non-parseable.
While at it, split the method into a "get keyword name from input
line" and "is a valid keyword name" part. (this will be needed later.)
It seems like some optimization passes of CLang which are enabled by
-O2 (at least in my version, 3.3) do not like nested scopes and long
functions too much. Thus, slightly change the generated source. Timing
on my (quite beefy) machine:
without patch:
make
rm -rf generated-source; time make
time make
[...]
real 10m31.110s
user 10m16.264s
sys 0m13.672s
with patch:
make
rm -rf generated-source; time make
time make
[...]
real 0m47.011s
user 0m44.670s
sys 0m1.968s
the memory used by the compiler goes from 28.8GB to about 330 MB. (I
suppose not everybody has 32 Gigs of memory yet. ;)
it turns out that boost::regex does not work for the libstdc++ debug
mode. This patch should fix this for sufficiently new compilers.
Note that this requires the FindCXX11Features.cmake tests pulled in
from opm-core and an additional compiler flag...
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.
