> How to handle the situation when the deck asks for something we do not > support? Of course a warning is a natural solution; but if we just succumbed > to a warning immediately I fear people would generally not even notice, and > we would have lost the opportunity for a more principal discussion.
I hope we have room to do both. That is, implement a warning, but still seize the opportunity to do a principal discussion. I do see your concern though. Hence, I favour 2 b) with the addition that we prefer warnings to throws when unsupported input parameters are used. At least if there are sensible ways to continue the simulation. I believe this issue also surfaces for keywords themselves, not only their input parameters. I believe the current MINPV and PINCH handling demonstrates a pragmatic (rather than strict) approach to this. MINPV and PINCH is not implemented according to the specification of the keywords, and we have already agreed on a custom keyword to specify the currently supported behaviour. Still the simulator is set to run through with the implementation we have with the default deck without throwing. At the same time we are spending significant resources implementing MINPV and PINCH according to their specification. I do not see the need to prioritize the correct MINPV+PINCH implementation higher. A throw in this case would be very unfortunate. There is of course an issue of priorities. Throwing will force us to prioritize a strict implementation of every keyword. With keywords like RPTSCHED in the pipe-line, I am a bit uncertain if any of us wants that. On a more general note, I am not even sure there is a need to force priorities this way. On another general note, we have already several simulators in OPM that uses the parser. Hence, it may not be practical for the parser to decide when to throw based on input parameter values (as different simulators support different functionalities). It is probably more sensible for the parser to simply provide the input parameters in the Eclipse state, and then let it be up to each simulator whether to throw or give a warning. The parser should probably only be concerned with the parsing, and whether the parsed file is formatted correctly. The parser cannot realistically (and probably should not) keep track of all it's downstream users anyway. As such the https://github.com/OPM/opm-core/pull/812 is a bit special, since it is input parameters related to the ouput writer. For the output writer, their is only one solution, and the same developers work on it and the parser. Still, a straight forward example where throwing even in this case is unfortunate, is if Resinsight used the parser. Resinsight would not care about the output writing configuration (it is only interested in input properties), suddenly we would have a large collection of frustrated Resinsight users on our hands since they are not able to open their models any more. Cheers, Alf ________________________________ From: Opm [[email protected]] on behalf of Joakim Hove Sent: Wednesday, June 03, 2015 10:43 AM To: [email protected] Subject: [OPM] Improvements(?) in opm-parser Hello; lately we have seen several examples of the following pattern: 1. New code is added to the Parser; typically partially supporting a new output configuration. 2. Existing decks make use of features not (yet) supported by Opm (be that parser or downstream modules) and an exception is thrown. Since the features raising the exception were previously plain ignored this obviously feels like a regression for the downstream developers. Examples of this behavior include: https://github.com/OPM/opm-parser/pull/470 and https://github.com/OPM/opm-parser/issues/487. In addition a related topic is coming up here: https://github.com/OPM/opm-core/pull/812 I am posting this here in the hope of creating a general discussion on two topics: 1. How to handle the situation when the deck asks for something we do not support? Of course a warning is a natural solution; but if we just succumbed to a warning immediately I fear people would generally not even notice, and we would have lost the opportunity for a more principal discussion. Of course an important caveat for this discussion is that it only applies to the things we know that we don’t support, for instance regarding the summary configuration the code is completely oblivious. 2. The issue raised by Atgeirr in: https://github.com/OPM/opm-core/pull/812 is the question of input parameters versus deck configuration. As I see it there are roughly three alternatives: a. Completely ignore the input deck. b. Initialize based on the input parameters, and then apply deck configuration if/when it appears. c. Completely ignore the input parameters. Alternative b) would apply in the case we are considering properties which are manipulated in the Schedule section. Consider for example the RPTRST which controls the output of restart data: -- Setting RPTRST section in the SOLUTION section; this will be overwritten by the input parameters. SOLUTION RPTRST value1 / SCHEDULE TSTEP … / -- Changing the RPTRST settings partly into the simulation; this will apply - i.e. from now on we respect the deck. RPTRST Value2/ The ability to overwrite the initial part of the IOConfig object is not yet implemented, but that is in the pipeline. Another example of the same is the Tuning class which internalizes (some) of the TUNING keyword content, and also can update the initial default value to support alternative b) behavior. This class is not used yet. So – what do you think? Joakim RDI project with IT elements -> Contact R&D Toolbox<https://statoil.service-now.com/selfservice/catalog_item_detail.do?sysparm_document_key=sc_cat_item,78bfbbce6fb455001f6446916e3ee453> ------------------------------------------------------------------- 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
