Den 4. okt. 2013 kl. 14:48 skrev Kristian Flikka: > Hello; > > the parser code is progressing steadily - if not lightning fast - in the > right direction. The current status is: > > 1. We have a bug with string keywords with emebedded spaces. > 2. We are adding keywords to the list: > https://github.com/OPM/opm-parser/tree/master/opm/parser/share/keywords - we > are aiming at all the keywords in the Norne case, current status is <~ 50% > complete.
It sounds like the most important parts are done, I assume that the remaining half of the Norne keywords are less important ones. > > When these two items are completed we aim to start integration with opm-core, > for that process we would very much like to hear opinions from the rest of > the OPM community. The current plan is roughly: > > 1. Create a thin - but growing layer ~ EclipseState which understands(?) > ECLIPSE idiosyncrasies and combines information from the deck accordingly. > 2. Write opm test applications to parse using both existing parser technology > and the new parser. > 3. Replace with new Deck / EclipseState functionality on a feature for > feature basis - see below. This sounds like a good plan. Initially I assumed the EclipseState class is going to be a part of opm-parser, and that most simulators would extract their properties from that. However, there are some calculations (transmissibilities for example) that are performed by code in opm-core, that probably would be needed to make the EclipseState work properly (transmissibility multipliers for example). So perhaps that needs to be part of opm-core? Or can we do it in another way? > > When it comes to grouping of Eclipse features we have identified the > following: > > Tables : The keywords like PVTG and SWOG and ... contain the data for one or > several tables in a quite arcane format. We suggest to implement a class > EclTable which can be populated from the Deck. Sounds good. Will this automatically interpolate tables where there are defaulted data? > > Grid and properties: Creating the ECLIPSE grid from COORDS / ZCORN / ACTNUM > and loading the various property keywords like PORO and PERMX. This topic > will require supporting the various manipulation keywords like MULTIPLY, > EQUALS, COPY, .... For this task I would very much like to make ERT a > required dependency. Why does this require ERT? > > Time stepping/schedule: Basically everything about the Schedule file. This is, for me, a very important part. Have you designed this yet? In that case, I would be very curious about your proposed interface for accessing this. > > Any opinions on this very welcome. As we consider the "Tables" properties to > be the smallest we suggest to start there; but we are open to opinions. > > As this will probably be a long lasting task - it would be nice if we could > get the required "Umph" to create and manage a upstream branch at opm-core? I have to admit I do not know what you mean with 'upstream branch'. Is it a branch of opm-core that depends on opm-parser? We have so far tried to not have long lived branches on the OPM/opm-core repository (the cmake branch was one, but that also showed some of the difficulties). We should certainly investigate if there is a dependency in the other direction first (for example due to the transmissibility multiplier issue). I am a bit unsure about the long-term set of modules. I am reluctant to have opm-core depend on other opm-modules (or additional external libraries). Perhaps we should make a module opm-simulators that depends on opm-core and opm-parser but keep the solvers in opm-core? Or perhaps opm-parser should even be a part of opm-core? I think parts or modules that are going to be very frequently used should be considered for inclusion in opm-core, to keep the number of modules managable. Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
