search

OPM / opm-parser

http://www.opm-project.org
11 stars 44 forks source link

Fails to parse ROCK if ROCKOPTS use ROCKNUM #1228

Closed berland closed 4 years ago

berland commented 4 years ago

If a deck declares item 3 of ROCKOPTS to ROCKNUM, the number of records in the ROCK keyword is no longer NTPVT as declared in https://github.com/OPM/opm-parser/blob/master/lib/eclipse/share/keywords/000_Eclipse100/R/ROCK

but rather the max (I suppose) of the ROCKNUM region parameter.

Trying to build a deck object of such an input file gives an exception depending on what comes next after the ROCK keyword, as it does not know how many records to parse, example error message:

Failed to parse keyword: ROCK
Starting at location: ....

Inner exception: Malformed floating point number PVTW

Is this feasible to fix/mitigate? (I don't need to support ROCK/ROCKNUM, I only need to be able to parse other portions of the deck)

berland commented 4 years ago

Disclaimer: Only tested with opm-common with the tag release/sunbeam/2019.02

alfbr commented 4 years ago

Thanks for the report! Please note that opm-parser is only kept for historic reasons. All development is in opm-common, and issues should be reported there.

joakim-hove commented 4 years ago

I have copied the issue over here: https://github.com/OPM/opm-common/issues/1357