> 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. That was also our plan. 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? I am briefly aware of this case; my very immature first reaction was that e.g. the transmissibility calculations could be moved from opm-core to the the opm-parser? But - I guess my main suggestion is to start with the simple things, and wait with the more complex dependency features like transmissibility? > > 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? Well - it is not implemented yet :) But yes - suitable interpolation is certainly a expected feature. > > 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? It does not require ERT as such - but quite many of the general "manipulate-a-field" workflows are already implemented in ERT. In particular grid related stuff - e.g. supporting the MINPV keyword. > > 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. No - we have hot designed it. I have implemented a Schedule file parser in ERT - which is not very good. To me one of the main learnings from this exercise was that the Schedule file format is a bit deceiving, it gives an impression of being an assembly of self contained blocks, but can actually not be interpreted in meaningful way without keeping a "current state" in mind. For instance: DATES 1 JAN 2005 / / WCONHIST OP1 ... 1000 / OP2 .... 2000 / / DATES 1 FEB 2005 / / WCONHIST OP2 ... 3000 / / What is the oil production rate in well OP1 at February 15.th - it is still 1000. My only moderately sucessfull experience with Schedule file parsing was related to creating data structures which in a simple way reproduced this behavior. > 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). Well - I made up the concept "Upstream branch" all by myself, it was obviously not very successful. My thought was that the integration of opm-parser functionality/dependency in opm-core would take quite long time, and it would be convenient for Kristian and myself to have a opm-core branch which we could use as focal point for our common development. So yes - that would be a branch were we would introduce and test out how opm-core should depend on opm-parser. I understand your reluctance with respect too long lived branches - my main point here is that I think it will be difficult / impossible to plan this to perfection in advance, we must try out things - get experience and so on. If all of that work is done outside OPM/opm-core/master the final PR will be massive and difficult to review. As for the direction of dependencies I think that alos will be difficult to plan to perfection before we have tried things out. My current concrete suggestion is: 1. We create a PR for opm-core which will induce a build-time dependency on opm-parser. 2. We implement code for internalizing tables in EclipseState. 3. A PR is submitted to opm-core making use of the new opm-parser functionality? Sounds feasible? 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. I am certainly open to the possibility that opm-parser should be part of opm-core. 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
