Den 26. aug. 2013 kl. 16:24 skrev Joakim Hove: 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 Thank you for doing this, I had a build failure though (reported as issue), but it can be easily fixed. 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? I agree with your proposed plan, and I think it can be kept separate from opm-core for now. It may be more natural to move deck-reading simulators out of opm-core rather than moving the parser into opm-core, some people think opm-core is too big already. But so far, it is fair to keep the parser and EclipseReservoir in opm-parser and make a branch in opm-core that uses it (eventually). I have not yet looked closely at the API, so I cannot give useful feedback on that yet. How would you like the status of opm-parser to be for the 2013.09 release of OPM? Acknowledged but experimental? Not part of the release? Fully official part of the release? Atgeirr
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
