My take on this is that we need to decide whether we want to support the MESSAGES keyword. I believe it is commonly used and expected as a configurable option (I have appreciated it and used it myself on occasions), so I believe the answer is yes. If we agree on supporting the MESSAGES keyword, then I believe it is reasonably clear how to proceed.
Cheers, Alf ________________________________ From: Opm [[email protected]] on behalf of Joakim Hove [[email protected]] Sent: Tuesday, December 09, 2014 6:14 PM To: [email protected] Subject: [OPM] Strict parsing Hello; Andreas currently has the following two PR's against OPM-parser: https://github.com/OPM/opm-parser/pull/355 https://github.com/OPM/opm-parser/pull/347 One of them has title "Remove the strict parsing concept" and the other one is about how to handle defaulted, and particularly defaulted items without a properly set default value. The "srict parsing" behaviour of the parser was quite mediocre, and I support that removal. However - both of these PR touch upon the general balance which must be found between strictness and correctness and ease of use and flexibility on the other hand. Andreas and myself have discussed this at some length, but it is an important topic and I would therefor like it if others joined with comments. I have not personally hammered out a vision of exactly how this should be, so I must admit that my review comments and decisions have not always been as well thought out as they should. The direction I would like to stear against for these questions can be summarized as: The parser: The parsers should serve as a glorified tokenizer; i.e. it should correctly split the contents of the file into keywords, records and items - and the items should be parsed as correct fundamental type (i.e. string/int/double). This means that the parser should raise an exception in the following situations: 1. Failed to open include file. 2. Can not parse item - i.e. "xxx" is not a numeric type. 3. Getting confused with record/keyword termination. These things should be OK: 1. An unrecognized keyword (and thereby ignored) (current status: throw) 2. <?> To short keywords <?/> [This currently throws - Andreas has a PR on that as well] 3. Missing keywords. 4. Keywords out of order or in wrong section. 5. Keywords with invalid values (i.e. PERMX < 0) 6. Invalid Keyword <-> Keyword interactions; i.e. MULTREGT based on undefined numerical array. Observe that points 1 & 2 on the white-list are potentially in conflict with point 3 on the black list, i.e. relaxing these two points will increase the chance of confusing the parser, i.e. it can loose track and end up with an exception. EclipseState: For the EclipseState object I want to be strict. As I see it there are two levels of strictness which can be enforced on the EclipseState: 1. We can require that all supplied input is consistent - otherwise we throw. I think that is quite close to the current state; altough we are relaxed when it comes to section ordering. 2. We can require that all necessary input for a simulation is present - that is currently quite far from the situation. I.e. the EclipseState constructor will happily return a "valid" object even if the input deck does not provide any PERMX values - or a directive for how the initialization should be performed. If we are to provide a guarantee of the type 2 above I think it should be done with an abstract CheckEclipseState() class - then different simulators can provide custom checkers. Furthermore I guess it would be valuable to make more subcomponents in the EclipseState object - so that e.g. properties can be fully validated even if you do not have any Schedule data. This would be even more important if the EclipseState is made even stricter. Logging of warnings & errors: It is good to have a log - but the log object/file should have any role in enforcing/verifying correctness in the input. Comments highly appreciated. jaokim ------------------------------------------------------------------- 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
