Program threw an exception: PARSE_UNKNOWN_KEYWORD

[OPMUSER]

Parser threw exceptions for the following keywords:

1. UDQPARAM
2. UDQ
3. ASSIGN
4. DEFINE
5. UPDATE
6. UNITS
7. ACTIONX
8. ENDACTIO

See the attached file for reference.

PAS-P50-C55.zip

It would be more efficient to to print the keyword and continue rather than abort.

[joakim-hove]

Thank you for the list of keywords; I guess we can add Json definition files for these keyword, but to support all of them fully in the simulator is a quite significant task. Not clear to me whether that will be prioritized.

It would be more efficient to to print the keyword and continue rather than abort.

Yes it would - the reason we do not do that by default is that the moment you encounter an unknown keyword the parser state becomes fragile, and the risk of further silent errors in the subsequent parsing is quite large.

But you can set an environment variable before running flow, which will give this behavior:

bash% export OPM_ERRORS_WARN=PARSE_UNKNOWN_KEYWORD
bash% flow CASE.DATA 

Then you should just get a warning when unknown keywords are encountered, but mind my warning about consecutive problems/errors.

[OPMUSER]

@joakim-hove If Eclipse does not recognize a keyword then it is an error and the simulation will not run, I would suggest that we do the same as a default, but if OPM Flow recognizes a keyword but does not use it then that should be warning and the simulation should proceed.

I agree there are far too many keywords to document, is there a more efficient way to flag these unrecognized keywords without defining the structure and to treat them as errors?

Also I tried your suggestions by setting:

export OPM_ERRORS_WARN=PARSE_UNKNOWN_KEYWORD

I then activated the unrecognized keywords

I only got a warning for the MULTNUM, the last offending keyword, what we should have is warning/error messages for all.

Also, I'm currently writing the OPM FLow documentation manual, I think it would be better to put all the environment tweaks in the *.parameter file, so that the user only has to edit two files (input deck and the parameter file to run the deck). Is that possible?

[atgeirr]

I think it would be better to put all the environment tweaks in the *.parameter file, so that the user only has to edit two files (input deck and the parameter file to run the deck). Is that possible?

The ParseContext settings could certainly be manipulated through command line parameters (or a .param file), but it would be less flexible -- we would have to choose which particular settings to expose.

[joakim-hove]

I only got a warning for the MULTNUM, the last offending keyword, what we should have is warning/error messages for all.

The warnings should go to the PRT file - are you saying that is not the case?

[OPMUSER]

There is no PRT file or .DEBUG file this instance. ThunderBird Signature File Regards, David Baxendale Email: [email protected]

…

------------------------------------------------------------------------

On 2017-08-09 16:01, Joakim Hove wrote: I only got a warning for the MULTNUM, the last offending keyword, what we should have is warning/error messages for all. The warnings should go to the PRT file - are you saying that is not the case? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARIIDyXYzuiZzXV5yuB_DxZUVnxeHHbSks5sWWdLgaJpZM4Oxn9r>.

[joakim-hove]

There is no PRT file or .DEBUG file this instance.
ThunderBird Signature File

OK - @atgeirr : comments?

[atgeirr]

Perhaps, if we abort during parsing we might not log/convert the messages from the parser's message container? Just a guess, I have not investigated this.

[joakim-hove]

Perhaps, if we abort during parsing we might not log/convert the messages from the parser's message container? Just a guess, I have not investigated this.

Ahhh - that makes sense; the MULTNUM bug described here #1115 aborts the whole thing.

[OPMUSER]

Okay, I got passed all the warnings etc. that were printed to the terminal, and OPM Flow appears to run - but it does not as you can see below:

flow PAS-P50-C55.DATA |& tee PAS-P50-C55.LOG
**********************************************************************
*                                                                    *
*                This is flow_ebos (version 2017.04)                 *
*              (eWoms version: 2017.04.0 ("Fabienne"))               *
*                                                                    *
* Flow is a simulator for fully implicit three-phase black-oil flow, *
*            and is part of OPM. For more information see:           *
*                       http://opm-project.org                       *
*                                                                    *
**********************************************************************

Reading the deck file 'PAS-P50-C55.DATA'
baxendale@baxendale-VirtualBox:/media/sf_Linux/OPM Flow/Pasca-A$ 

There is no DEBUG or PRT files either.

This deck runs under Eclipse and tNavigator without any issues., so it is a good real world test case. I have disabled the ACTION and UDQ associated keywords and made some other modifications to get it to "work". However, without a PRT file I cannot proceed any further.

Note I am just testing OPM Flow 's functionality with some real input models. I'll HOLD for now until we have a fix.

[joakim-hove]

Hmmm - I can not find any of these keywords in the Eclipse100 manual: [ASSIGN, DEFINE, UNITS, UPDATE] - are they Eclipse300 keywords? Or am I looking in the wrong place?

[OPMUSER]

I know not obvious, they are part of the UDQ - User Defined Quantities keywords so look under UDQ and are available for both E100 and E300.

This and the ACTION set of keywords are use to "program" Eclipse. The syntax for both ACTION and UDQ keywords is horrible, if we were to add similar functionality to OPM Flow, then I would suggest that we use a ResInsight approach instead; that is just use OCTAVE or R with hooks to OPM Flow.