Error: Saturation Tables

[rcgz]

The run generates the message that is in the image, so it does not allow to initialize the model. It tells me that an ECL file could be the error, but I don't have any file with this name or maybe I'm confused.

Can you help me by telling what went wrong please

thanks

[blattms]

What the error message tells you is that in your model the water phase is active and in that case the simulator is expecting the SWAT keyword, but it did not find it in your data files. Does this run with other simulators? Then we are maybe more strict. Can you check whether you SWAT in your data files.

By ECL file we mean the *.DATA and any file that is (recursively) included by it.

[OPMUSER]

@rcgz I'm sure what is going on here without further information, but the SWAT array is used for the non-standard method to initialize the model via enumeration and is seldom employed in the industry. So if you not using enumeration to initialize the model then something else is amiss.

Hard to help without further information, but I would suspect that there are typos in your input deck that are causing the problem.

[bska]

I'm inclined to agree with @OPMUSER here. The deck is probably missing the initial water saturation for the "enumerated" initialisation method. For what it's worth, the command below will extract a linearised list of keywords read from the input file without divulging potentially sensitive information like file, well, or group names. Here CASE.PRT is the .PRT file created as part of running the simulator on your simulation CASE. If you'd like some additional assistance I think we'll at least need that list of keywords. If you're able and willing to share your model too then that will probably make it still easier for us to assist you.

---

sed -n -E -e '/^ *([0-9]{1,}) *Reading *([A-Z][A-Z0-9_]{1,}).*$/s//\1 Reading \2/p' CASE.PRT

[rcgz]

The model has already been initialized, but the simulation takes too long, 20 hours have passed in the run and only 3 days of simulation have gone by. It mentions a convergence problem, I think it is due to the keywords TUNING or TIGHTEN, could it be?, and if so, is there any option to solve it? Could you please help me Thanks.

[OPMUSER]

Yes there are ways to improve numerical performance, but unlike my better half I cannot read your mind. If you want help then you need to provided more information. Some suggestions:

• Provide run output as suggested by @bska
• Check all warning messages and try to fix as many as possible, they are there for a reason. Most numeric issues are due to data input, inconsistent PVT, different PVT regions in communication, analytical aquifers directly connected to hydrocarbon zones, etc.
• Add the PERFORMA keyword in the SUMMARY section to output numerical data to the SUMMARY file, provide this and the print file.
• The TIGHTEN keyword is no supported.
• Only the first line of TUNNING keyword is supported and you must set enable-tuning=true in the parameter file for OPM Flow to use the keyword.
• Provided an example test deck with the issues that we can use to debug your issue. Perhaps strip out all comments from the deck and include files, change well names to OP01, WI01, etc. so that they are generic.

Without further information it is not possible to offer any assistance.

[rcgz]

sorry, I'm new at this. the file that was generated does not allow me to share here, could you share it in another way?

[OPMUSER]

Probably because GitHub only allows certain files to be uploaded. You can get around this by compressing the files into a ZIP file and then uploading the ZIP file.

If you are running NoScript in your browser make sure that github is temporary trusted or trusted.

[rcgz]

HM_FP_POES.zip

that is the file that was generated

[OPMUSER]

@rcgz thank you for this and thank you @bska for the regex magic (I'm going to incorporate this into OPMRUN when I get a minute, as it would be a helpful debugging tool for all users).

Now that we have some information, and before we try getting this to run using different solvers please do the following:

Step 1: You need to fix these errors with the saturation tables, I'm not saying this will fix the problem, but it is always good practice to fix these type of warnings first.

Warning: In saturation table SATNUM = 15, Sgmax should not exceed 1-Swco.
Warning: In saturation table SATNUM = 23, Sgmax should not exceed 1-Swco.
Warning: In saturation table SATNUM = 27, Sgmax should not exceed 1-Swco.
Warning: In saturation table SATNUM = 30, Sgmax should not exceed 1-Swco.
Warning: In saturation table SATNUM = 32, Sgmax should not exceed 1-Swco.

Step 2: Check that this is correct:

Warning: Equilibration region 31 has no active cells

Step 3:

Run the model with no production to test the equilbration, for say 365 days. You can do this by inserting the following at the beginning of the SCHEDULE section.

--
--       ADVANCE SIMULATION BY REPORTING TIME
--
--       JAN  FEB  MAR  APR  MAY  JUN  JLY  AUG  SEP  OCT  NOV  DEC
TSTEP
         31   28   31   30   31   30   31   31   30   31   30   31
/

END

Now if there pressure changes and there is fluid movement then this means the model is not in equilibrium, so we need to fix this before continuing.

Switch off all the aquifers so that there are no aquifer connection and no aquifers in the model, and then run the model as before with no production data. Did that fix the non-equilbrium issue? If it did, then that means the aquifers are not in equilibrium with the hydrocarbon zone. So you need to fix this. You can do this by switching on one aquifer at a time to see which one is causing the issue (there may be more than one), and you may also have individually test the AQUCON and AQUANCON statements for a given aquifer. Looking at the aquifer connections in OPM ResInsight should point you in the right direction.

If the model without the aquifers is still not in equilibrium, then this could be due to different PVT regions being in communication, so check for flow between different PVT regions in OPM ResInsight by checking the pressures. See the MULTREGT keyword in the GRID section on how to do this.

It may also be that you have communication between different equilibrium regions, so this needs to be fixed, by isolating the offending regions. See the THPRES keyword in the SOLUTION section on how to accomplish this.

Step 4 Once the the above have been resolved, re-run the corrected model with production. Do you still have problems? Report back and let me know the status.