Hi, Thanks for sharing this issue, and let me say that with this parser you are doing a great job! I have not updated my version of the parser since September, so sorry if I some of my comments are outdated. Hopefully I will update soon.
With regards to the levels of strictness I believe the parser should parse whatever is available in the ECLIPSE input deck, without throwing any error if there are keywords missing for a simulation. I think it is important to have an adequate warning system though, for example a warning log saying what has been parsed successfully, and what was attempted to parse but failing (incomplete keywords, etc). What's needed for a simulation is strongly dependent on the simulation model adopted, and I think the idea to have a check class (e.g. CheckEclipseState() ), which is model dependent is the way to go. This gives also the flexibility to the parser user, to do or not the check, and to build is own check for a specific module. I also like your idea to make more subcomponents in the EclipseState object, this type of modularization is perfectly in line, and general enough to cover different simulation model needs. For example, for a simulation I might want only the grid property, and I don't need the schedule. But again, if some of the grid properties is missing, the parser should not throw an error, only clear warning, while a checker invoked by the specific model will have to stop the run if a certain grid property is required. My main point is: let's split the parsing function, from checking what's needed for the simulation. Thanks Paolo On Wed, Dec 10, 2014 at 2:16 PM, Alf Birger Rustad <[email protected]> wrote: > 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 > >
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
