I am not sure that is a good idea. It depends on what we want to accomplish I guess, and putting restrictive names on projects may end up restricting it unnecessarily in practice. In this case there are two issues. One is do we really want to restrict opm-parser to Eclipse formats? The reason we implement support for Eclipse formats is because of its dominating market position and what that entails. Moving forward though, I do think we at some point want to support at least one additional input format, and I do believe that the current design of opm-parser is a good starting point for that. Secondly, I believe having basic IO routines spread out across repos makes no sense other than creating sandboxes for developers. I believe parsing belongs in a common library along with other shared functionality, which is not exactly what opm-core is today. Making a library optional fine, but I do think a simulator needs input format, and this is all we have, so I am not sure the solvers will be of much use without it currently. Hence I suggest keeping the opm-parser name for know, but that we set a side some time to review our repository organization later this year.
Cheers, Alf ________________________________________ From: Opm [[email protected]] On Behalf Of Joakim Hove [[email protected]] Sent: Monday, January 27, 2014 10:09 AM To: [email protected] Subject: Re: [OPM] Use of ERT in Parser? Sounds like a good plan. In the not-so-distant future we might consider renaming opm-parser -> opm-eclipse? Joakim -----Original Message----- From: Bård Skaflestad [mailto:[email protected]] Sent: 24. januar 2014 11:29 To: Joakim Hove; [email protected] Subject: RE: Use of ERT in Parser? All, Joakim, Just a brief comment. I think that in the interest of short-term progress it's fine to make the ERT a "REQUIRED" prerequisite for opm-parser (and thus OPM proper). In the long term, we should probably coalesce all ECL support (I/O, object construction &c) to a separate, optional, module so that it once more becomes possible to use OPM solvers (for instance) without ECL support. Bård ________________________________________ From: Opm [[email protected]] on behalf of Joakim Hove [[email protected]] Sent: 24 January 2014 08:46 To: [email protected] Subject: [OPM] Use of ERT in Parser? Hello, In the OPM-Parser work we are now close to start working on the GRID and PROPERTIES and ... section of the ECLIPSE datafile. Of the slightly more complex aspects of this work is to support the BOX and numerical modifications of keywords; like MULTPV and ADD and ... Much of this functionality is already implemented in ERT, and I would like to use that. But if we start using ERT this way the dependency will become required, and no longer optional. Opinions? 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 ------------------------------------------------------------------- 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 ------------------------------------------------------------------- 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
