> We'll burn that bridge when we get there; I believe we are already there, the option is irrelevant for Resinsight. I believe it is irrelevant for a number of simulator use cases too. My point being that keeping track of all modules and their use cases is already non-trivial, so by design it makes more sense for the modules themselves to decide whether to throw on unsupported options.
Cheers, Alf From: Opm [mailto:[email protected]] On Behalf Of Joakim Hove Sent: 3. juni 2015 14:57 To: [email protected] Subject: Re: [OPM] Improvements(?) in opm-parser >What if one downstream module supports it, but another doesn't, and for a >third module the option is irrelevant? We'll burn that bridge when we get there; but quite frankly I do not see that we will ever get there. We (try) to adhere to the DRY principle in this part of town, and that means that capabilities like e.g. writing a grid is only implemented one single place - i.e. either Opm modules have access to a .GRID writer or they don't. If application logic in one downstream module decides to not make use of that capability is of course another matter. J ________________________________ From: Opm [[email protected]] on behalf of Joakim Hove [[email protected]] Sent: Wednesday, June 03, 2015 12:39 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPM] Improvements(?) in opm-parser There is of course an issue of priorities. Throwing will force us to prioritize a strict implementation of every keyword. Well; let us walk through the GRIDFILE keyword - that is a good illustration of the situation: 1. Opm simulators will output an .EGRID file unconditionally; that is also the default if no GRIDFILE keyword is present. 2. In: https://github.com/OPM/opm-parser/pull/470 the parser is explicitly aware of the default behavior and the semantics of the GRIDFILE and NOGGRF keywords are correctly accounted. 3. The old SPE decks explicitly ask for .GRID output - we do not support that. At point 3 I see three possibilities: 1. Throw an exception since the input deck asks for something we know the downstream modules can not support; to proceed the user should then update the input deck by modifying the GRIDFILE keyword - that has been done here: https://github.com/OPM/opm-data/pull/47 2. Print a warning and don't give a shit. 3. Implement support for .GRID output. I strongly prefer alternative 1). I want the parser output to be taken seriously by the downstream modules; it should not be so that we configure EclipseState objects based on the input and then silently ignore them at will. If the common consensus is that for less important things like output configuration we do not really intend to follow the specifications in the input deck we should not even internalize that information - that might be a good alternative. The parser should probably only be concerned with the parsing, and whether the parsed file is formatted correctly. That is a long time ago; all of EclipseState is one semantic layer above this. J ------------------------------------------------------------------- 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 ------------------------------------------------------------------- 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
