Dear OPM community, the parser for the ECLIPSE datafile is coming along quite nicely. There is certainly more work to do, but we feel it has reached a level where it is interesting to show the current state of the parser and our immediate future plans, and most importantly discuss how this should be integrated with OPM-core.
Current state: We have implemented a parser which knows about the concept of keywords, records and items, i.e. the structure of the ECLIPSE datafile. However the parser does not know anything about the specifics of the ECLIPSE keywords, that is all entered as configuration dynamically. Some basic documentation can be found in: https://github.com/OPM/opm-parser/blob/master/docs/keywords.txt Short term plans: 1. Simplification of the json 'schema' for keyword configuration, in particular for grid properties. Add value sets to the config items; i.e. the state of a well can be 'OPEN' or 'CLOSED' - not just any string (which is the case now). 2. Add help items as part of the configuration? This could very cheaply give us an application which could be used to print keyword documentation on stdout, maybe a very simple way to sneak some 'OPM' usage into Statoil? 3. (Add keyword config objects)^N and (try) to parse various statoil internal datafiles. 4. Pimp build system to embed the default keyword definitions in the binary; might need some help for a skilled CMake voodoo priest on this. 5. ???? Long term plans / Integration with opm-core: Now the most important topic we would like to discuss with the rest of the OPM community are along two partly related axis: 1. How long should the parsing go? The current parser can create a deck representation where all the keywords in the file are internalized and can be accessed as the right datatype+++. However, there is no 'global ECLIPSE knowledge' combining keywords into a complete reservoir description. I.e. the situation: PORO LOTS_OF_VALUES / BOX 10 12 10 12 1 3 / PORO SOME_VALUES / Should ideally generate one PORO field with correct values; currently we will only have three keywords PORO, BOX and PORO with their accompanying data. The current status is an essential stepping stone. One could say that the current situation is good enough, or one could build an additional layer on top which understands the "reservoir-semantic" content of the ECLIPSE keywords. That was the original plan - but we have not started it yet. In principle such a EclipseReservoir class could of course start out as a quite thin layer on top of the parsed DECK. 2. How should this (parser / EclipseReservoir) be used with opm-core? I guess the basic question is whether it should be integrated into the opm-core source, or if the parser should be a separate library? My personal suggestion/preference on these topics: 1. We create a EclipseReservoir class, but that is a quite thin container atop of the parsed Deck. 2. We start by keeping the parser as a separate library. We create a opm-core branch using this library, and continue the discussion from there? Joakim ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
