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
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
