Den 10. apr. 2013 kl. 10:49 skrev Kristian Flikka: > Hi! > > We have now started developing the <opm-parser> module for parsing of the > Eclipse input data format. So far the parsing only consists of reading and > tokenizing the input. Our plan is to use three class hierarchies named > Parser, RawDeck and Deck: > > Parser: This will be the main class driving the parser process; the list of > supported keywords, behavior++ will be implemented in this class. The parser > will not contain any state from the parsing process. > > RawDeck: In the pure-parsing step of the process the parser will populate the > 'RawDeck' which will consist of a list of keywords, where each keyword is > (essentially) a list of string tokens. > > Deck: When the pure string reading is complete the Parser will populate the > 'real' Eclipse deck where the different keywords have the correct type (i.e. > INT/BOOL/...), and most importantly the keyword-keyword dependencies are > taken into account
This sounds like a good approach. > The current code has a start of the Parser and the RawDeck classes, we have > not yet started on the Deck at all. We must take a couple of weeks pause from > this project now, but will pick it up again in the not-so-distant future. The > code can be found under github.com/OPM/opm-parser - comments and opinions > most welcome. > > We are using cmake, and ctest to build the module. Some of the test > executables require data that are "Statoil internal", and are not on github. > To skip the tests that are using the Statoil data, use ctest -LE "Statoil", > to get the actual output of the tests printed, use -V (ctest -V -LE "Statoil") The code built and ran on the first try. Kudos for that! If I have a comment at this stage, it would be that the interfaces are entirely undocumented. I think it is a very good idea to document early, even if it means you may have to change docs as interfaces change. This is because it is always hard to find the time and motivation to do it at later stages, and also because documenting an interface in a clear and concise manner forces you to think through the interface. I sometimes find that documenting an interface makes me change it, as explaining an issue gives me a better understanding. Good luck, Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
