SPE10MODEL1.DATA runs with failed results

[AaronyfDesign]

Hi, I've just started learning Flow tool in order to solving my own specific problem, and I was interested in running the following spe dataset. I'm now running opm Flow 2023.10 on an Ubuntu 22.04 system of a docker container. Every test result seems be to fine for running the following dataset of SPE1CASE1, SPE3CASE1, SPE5CASE1 and SPE9 with Flow, but it only ran into the anomaly while running the dataset of SPE10MODEL1.DATA, which said with the error message "Error: Unsupported keywords or keyword items:" and "Error: Unrecoverable errors while loading input: Problem with keyword".

However, when I ran SPE10MODEL1.DATA added the argument --parsing-strictness=low, it came the result with the 57.3% failed Overall Linear Iterations. I'm sure this result is correct as expectations or not. Is this an issue that anyone has come across before? Or this is for I didn't use the right command line argument to run the dataset SPE10MODEL1.DATA?

[atgeirr]

I am not quite sure what you are asking here. The failed iterations are a common occurence: whenever the simulator tries to take a timestep but fails, it will try again with a shorter step. The iterations that were performed for that step up to the point when we decide we have failed, are wasted and that is what is reported as Failed in the above output (newer versions of Flow has changed that to Wasted as it is more precise).

[AaronyfDesign]

Thanks for your reply. My problem could be summarized as the following list.

1. When we tested with SPE10_MODEL1.DATA and SPE10_MODEl2.DATA, the program reported "error: keyword NONNC is not supported" and "error: keyword OLDTRAN is not supported". Is this abnormal? We don't have the similar problem while running SPE1CASE1.DATA, SPE3CASE1.DATA, SPE5CASE1.DATA, SPE7CASE1.DATA and SPE9 form providing opm-data, so we wonder whether this is normal.

2. There is a test case of our own, it ran successfully on Eclipse and INTERSECT. However, when it was running on opm flow, the program reported “Error: Unknown keyword: PRTONLY” and "Internal error: EclipseGrid needs cornerpoint or cartesian keywords.". How can we solve these problem?

   Error: Unknown keyword: PRTONLY
   Error: Unrecoverable errors while loading input: Problem with keyword PRTONLY
   In SPE10-OWG.DATA line 135
   Unknown keyword: PRTONLY

   

3. We tried to add the command line argument --parsing-strictness=low for testing SPE10_MODEL1.DATA, and it did work as the following image. Did we handle it correctly? What do you do under this circumstance?

[bska]

I'll just comment on the RPTONLY problem here, because I haven't given enough thought to the remaining items. The RPTONLY keyword is supposed to be supported in OPM Flow, and has been since the 2021.10 release (October 2021). The diagnostic

Problem with keyword PRTONLY
In SPE10-OWG.DATA line 135
Unknown keyword: PRTONLY

therefore suggests to me that there might be some other issue that triggers the problem. Given that the model goes through in other simulators, it is probably still an OPM specific issue but in that case I think we'll need to know more about the model. Is RPTONLY entered in the SUMMARY section or in the SCHEDULE section–or maybe both? What is the keyword immediately preceding RPTONLY? If it's an aquifer keyword such as AQUCT or AQUFETP, then the problem may be an incompatibility. OPM Flow's input parser requires that such keywords be terminated by an empty record consisting only of a slash character (i.e., the / character).

Without know more about that model it is hard to give any specific advice here.

[gdfldm]

@AaronyfDesign I think Error: Unknown keyword: PRTONLY is simply a typo it should be RPT not PRT.

[gdfldm]

1. "error: keyword NONNC is not supported" and "error: keyword OLDTRAN is not supported"

@AaronyfDesign since SPE10 has a simple regular cartesian grid if you have defined it using DX, DY, DZ and TOPS then you should be able to simply remove the NONNC and OLDTRAN keywords from your input deck, since there should be no non-neighbour connections and the OLDTRAN transmissibility calculations will be used by default for a grid defined in this way.