>the option is irrelevant for Resinsight. Well - I will reiterate my case; we will burn that bridge when get there; last time I checked Resinsight was not using opm parser - and I am not aware of any plans to change that. Although I would be very pleased to be wrong on that point.
>I believe it is irrelevant for a number of simulator use cases too. Well - then users of said simulator should take the offending keywords out of their deck. >[...] so by design it makes more sense for the modules themselves to decide >whether to throw on unsupported options. That way we distribute the definition of semantically correct out to the consumers - a consequence of that is that the "contract/promise" provided by the Parser becomes much weaker - I think that is unfortunate. An approach I would like/suggest was that the creation of EclipseState:: subobjects was more modular - (on demand maybe??) - then problems would not arise before an unsupported property was actually used, that would be a bit like defaults are treated in the input deck: If a property without a default is defaulted - nothing will happen before you actually try to access that value. But anyway - the GRIDFILE keyword is mostly interesting as a simple and current example; much more interesting are the properties which can be controlled both by sprinkling keywords through the SCHEDULE section, and by the opm-core/properties system. This includes the TUNING keywords and also the configuration of the restart output mentioned in PR821. I hope more people will read through this thread and voice an opinion. J From: Alf Birger Rustad Sent: 3. juni 2015 15:17 To: Joakim Hove; [email protected] Subject: RE: Improvements(?) in opm-parser > 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]<mailto:[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
