OPM
Support for kw GUIDERATE or/and KWs longer than 8 characters
I'm having issues parsing an eclipse deck, due to lack of support for kw GUIDERATE. The error message returned from opm.io.Parser() is ValueError: Too long keyword:GUIDERATE
I have no need for parsing this particular KW, but this issue prevents me from parsing the deck for other purposes. Is there a general issue with KW longer than 8cha?
I see three different routes that could improve my situation:
- generic support for kw longer than 8 char
- support for this particular kw
- the ability to ignore unrecognized kws
ValueError: Too long keyword:GUIDERATE
Flow (and E100/E300) recognizes the keyword ~is~ GUIDERAT without the final E. Is GUIDERATE (with the trailing E) supposed to do roughly the same as GUIDERAT? Did you write the input deck manually or did you get it from some modelling software?
Thanks, for quick reply! My understanding is that Eclipse simply ignores trailing charters, so GUIDRATE and GUIDERAT is the same kw. I realize now that simply removing the trailing E will resolve my issue.
Would it be an idea to let the parser behave more like eclipse by ignoring trailing charters?
My understanding is that Eclipse simply ignores trailing charters, so
GUIDRATEandGUIDERATis the same kw.
I agree—that seems like the most plausible explanation. Characters beyond position 8 on the keyword line are treated as comments so GUIDERATE_FOR_BSKA would also likely be treated as GUIDERAT.
Would it be an idea to let the parser behave more like eclipse by ignoring trailing charters?
Yes, I think that would be a good idea. I don't know how hard it would be to implement though because I'm not deeply familiar with that part of the parser. I suppose @joakim-hove would know more about this.
Would it be an idea to let the parser behave more like eclipse by ignoring trailing charters?
If we do this (a simple truncation on all keywords longer that 8 characters), we will never be able to open for new keyword spesific for Opm Flow with more than 8 characters.
What worries me is that we doesn't seem to have a good error message from the simulator if this keyword is misspelled.
If I change GUIDERAT to GUIDERATE in file
opm-tests/model2/9_4E_WINJ_GINJ_GUIDERATE_MSW.DATA
and run with flow, I can't find any error message related to this. What I see is
174 Reading GCONINJE in file /project/multiscale/OPM/tskille/flowdaily_rh7/opm-tests/model2/9_4E_WINJ_GINJ_GUIDERATE_MSW.DATA, line 334
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
GCONINJE is last keyword before GUIDERAT in this deck.
Would it be an idea to let the parser behave more like eclipse by ignoring trailing charters?
If we do this (a simple truncation on all keywords longer that 8 characters), we will never be able to open for new keyword specific for Opm Flow with more than 8 characters.
We could add a command-line option (or a new OPM-only RUNSPEC keyword, e.g., LONGKW) that would enable longer keyword strings. Alternatively, we could have a matching rule that first tries the entire string and then falls back to at most eight characters if that fails.
I don't know how hard it would be to implement though because I'm not deeply familiar with that part of the parser.
Everything is suprisingly hard in this part of town.
Happy to have sparked the discussion! Unsupported kws will be around for a long time, i guess. An option to to make the parser ignore them would be handy for everyone using the parser for alternative purposes than running Flow.
An option to to make the parser ignore them would be handy for everyone using the parser for alternative purposes than running Flow.
That is already available through the ParseContext mechanism - see here for Python usage.