Could not find solution for PcEq = 0.0 after 60 iterations.

[ghost]

After scaling the relative permeability end-points of the model, I got the following error at 0 timestep: Program threw an exception: Could not find solution for PcEq = 0.0 after 60 iterations.

I'm trying to specify SGU as 1-SWL in the PROPS section. I'm guessing PcEq has something to do with capillary pressure equation, but I dont know what is wrong with it. Can anyone please help me with this?

[OPMUSER]

This could just be an inconsistency with the input data, rather than problem with OPM Flow. First thing to do is to check the print and debug files for any warning messages, and eliminate the warning messages if you can to make sure you have a clean deck. Then use ResInsight to look at the original relative permeability and capillary curves and see if there is anything unusual with the curves. Then do the same with the actual de-normalized curves used by OPM Flow in the calculations.

If you have multiple relative permeability tables then try using only one at a time to see if it is just one table causing the problem. You can do this via the SATNUM keyword. For example, if your model has 1,123,123 grid blocks then use

SATNUM
1123123*3
/

To set the model to use table number 3.

If everything looks okay, setup a test input file by using one of the SPE test cases with your relative permeability tables and see if you have the same problem. If so, upload the test deck so that it can be investigated further.

[ghost]

Thanks for the suggestions. I have tried the following so far:

First thing to do is to check the print and debug files for any warning messages, and eliminate the warning messages if you can to make sure you have a clean deck.

With the original input deck, Eclipse(2016.2) gives the following warning message regarding the end-point saturations:

--WARNING  AT TIME        0.0   DAYS    ( 1-JAN-2015):
 @           CONSISTENCY PROBLEM FOR OIL PHASE END-POINT                     
 @           (SGU > 1-SWL) IN GRID CELL (11, 1, 12)                          
 @           FOR SATURATION END-POINTS                                       
 @           SGU     =  0.771290                                             
 @           SWL     =  0.600000                                             
 @           (1-SWL) =  0.400000      

OPM Flow gives an error message at report step 0 : Error: [/builddir/build/BUILD/opm-simulators-release-2018.10-final/opm/autodiff/BlackoilModelEbos.hpp:887] NaN residual for Oil equation

The Eclipse warning message was solved by adding SGU = 1-SWL to PROPS section, as:

COPY
'SWL' 'SGU' /
/
MULTIPLY
SGU  -1  1 117 1 112 1 84  /
/
ADD
SGU   1  1 117 1 112 1 84  /
/

However, OPM Flow still crashes at time step 0 and prints this error message : Program threw an exception: Could not find solution for PcEq = 0.0 after 60 iterations.

Then use ResInsight to look at the original relative permeability and capillary curves and see if there is anything unusual with the curves.

I looked at the relperm curves that were generated by Eclipse with ResInsight and did not observe anything unusual (relperm.zip). However, when importing the EGRID file generated by OPM Flow, ResInsight gives a warning (RelPerm curve problems: Cannot Activate EPS without Backing Object) and the relperm window contains no plots.

If you have multiple relative permeability tables then try using only one at a time to see if it is just one table causing the problem.

I tried the method you specified for all of the tables one at a time in OPM Flow, but it did not help with the error. The only way to make the model run with OPM Flow is to set SWL to 0.2 (whereas SWL is 0.6 in the original deck, relperm.zip). Obviously enough, this is not a good fix as sensitivity tests with Eclipse indicate a significant deviation in the production trends.

If everything looks okay, set up a test input file by using one of the SPE test cases with your relative permeability tables and see if you have the same problem.

I have tried to create a test case to reproduce the same error with OPM Flow before opening this Issue post, but I was unsuccessful in creating a sample case.

[bska]

However, when importing the EGRID file generated by OPM Flow, ResInsight gives a warning (RelPerm curve problems: Cannot Activate EPS without Backing Object) and the relperm window contains no plots.

Just for completeness, that's a problem in OPM Flow's .INIT file. We're tracking its existence in OPM/ResInsight#3921.

[ghost]

@bska Thanks. I'm using 2018.11.2 version on Ubuntu 16.04 LTS for what it's worth.

[bska]

I had a look at the saturation functions in relperm.zip and there's nothing that stands out in the data. The oil/water capillary pressure (Po-Pw) is monotonically decreasing (to zero) with increasing water saturation and so should be invertible (if the initialisation code produces a non-negative capillary pressure value). On the other hand, the gas/oil capillary pressure (Pg-Po) is zero for all Sg, so there will be no solution if the initialisation produces a non-zero initial pressure difference.

Would you be able to share the EQUIL data for your model?

[ghost]

This is the structure of the SOLUTION section : EQUIL.zip. In order to preserve the confidentiality of the model, the data columns are multiplied with a coefficient. Is there any particular pattern in the data that I should check for?

[bska]

This is the structure of the SOLUTION section

Thank you very much. That all seems entirely reasonable. I take it that the gas-oil contact is above the formation and that there is no initial free gas? If so, the input data is fine as far as I can tell, and this really does suggest a bug in Flow's equilibration facility. I wish the diagnostic message issued in the equilibration helper would be more informative (e.g., include the phase name, the cell, and possibly the last state of the non-linear solver) to try to track down the underlying issue.

The problem may be related to the end-point scaling however, so would you be able to run a test that turns off end-point scaling (disables SWL, SGU, and SCALECRS) just to see if the model runs? Such a run will obviously not produce the correct result, but it may help narrow in on the problem area.

[ghost]

I take it that the gas-oil contact is above the formation and that there is no initial free gas?

Yes, that is the case. It is a black oil model, where oil is undersaturated at the initial reservoir pressure.

I wish the diagnostic message issued in the equilibration helper would be more informative (e.g., include the phase name, the cell, and possibly the last state of the non-linear solver) to try to track down the underlying issue.

I agree. It would be great if Flow indicated what is the problem with the input data that caused the error.

The problem may be related to the end-point scaling however, so would you be able to run a test that turns off end-point scaling (disables SWL, SGU, and SCALECRS) just to see if the model runs?

After disabling all three of those keywords, Flow still crashes and prints this error msg at time step 0:

Error: [/builddir/build/BUILD/opm-simulators-release-2018.10-final/opm/autodiff/BlackoilWellModel_impl.hpp:681] NaN residual found!

[OPMUSER]

Yes, I was going to ask about the phases present as well. So this is a three phase run with OIL, GAS and WATER phases declared in the RUNSPEC section but only OIL and WATER actually active in the model, correct?

Another question if SWL is set to 0.60, why are the SWL ans SWCR values significantly lower than this in the relative permeability curves? I would have though there would be similar to the SWL values Also are you re-scaling SWL SWCR and SOWCR, or just SWL? Also when you ran the test for @bska you switched off all endpoint scaling keywords including the ENDSCALE keyword in the RUNSPEC section, correct?

If you want, you could set up a test case by using your existing model and zero PV out most of the model, and send us the reduced model and then change the PVT if necessary. As long as it re-produces the error we can take a look at it.

Note also that just because Eclipse runs doe not mean that it is doing what you want, which is why I always like to look at the de-normalized curves the simulator is using.

One last point, if you have access to Eclipse do you have access to visualization software to display the resulting de-normalized curves, S3GRAPH for example?

[ghost]

So this is a three phase run with OIL, GAS and WATER phases declared in the RUNSPEC section but only OIL and WATER actually active in the model, correct?

OIL, GAS, WATER, VAPOIL and DISGAS phases are declared in the RUNSPEC. I'm not sure what you mean by active phases in the model, but in the PROPS section, I have included ROCKOPTS, ROCK, PVTW, PVTO, PVTG, DENSITY, SWOF and SGOF tables for all PVT regions in the model. SWATINIT and SWL values for all grid cells are specified individually.

Another question if SWL is set to 0.60, why are the SWL ans SWCR values significantly lower than this in the relative permeability curves? I would have though there would be similar to the SWL values Also are you re-scaling SWL SWCR and SOWCR, or just SWL?

Only SWL and SWCR are re-sclaled in the model. There is no clear explanation why SWL is set to 60% from the company that built the model, other than it was intended to lock the water in the grid cells with water saturation lower than 60%. I have no answer to why it is re-scaled to be higher than the values indicated in the relperm tables. As I mentioned previously, Flow only runs the model when SWL is re-scaled to 0.2 or lower.

Also when you ran the test for @bska you switched off all endpoint scaling keywords including the ENDSCALE keyword in the RUNSPEC section, correct?

That is correct.

If you want, you could set up a test case by using your existing model and zero PV out most of the model, and send us the reduced model and then change the PVT if necessary. As long as it re-produces the error we can take a look at it.

I've been trying to create a test case to produce the same error, but I get different errors due to the missing data as the model is reduced. I will attempt to do it again soon and will share it if I can manage to make it work (or not work).

Note also that just because Eclipse runs doe not mean that it is doing what you want, which is why I always like to look at the de-normalized curves the simulator is using.

I agree.

One last point, if you have access to Eclipse do you have access to visualization software to display the resulting de-normalized curves, S3GRAPH for example?

Yes, I do have access to S3Graf v.7.2.2718.

[OPMUSER]

I don't think this is the problem; but OIL, GAS, WATER, VAPOIL and DISGAS phases are declared in the RUNSPEC, seems strange as you only have a saturated oil and therefore there is no VAPOIL (or condensate in the model). Once the gas is liberated from the oil, that gas has zero liquid. We are not dealing with a gas cap (you said unsaturated oil) or volatile oil here, correct?

It is hard to say what is causing this without a test deck, but I think the problem is related to the scaling, and not the equilibration, I suspect that scaling is creating grid blocks with zero mobile oil or zero mobile water. I say this because the Sw points are being scaled up but the Sorw is being taken from the relative permeability tables. So check the SWL, SWCR, SWATINIT, SORW, and PC arrays in both the Eclipse and OPM Flow runs.

Also do you see very large values of Pc in the Eclipse version?

[ghost]

Once the gas is liberated from the oil, that gas has zero liquid. We are not dealing with a gas cap (you said unsaturated oil) or volatile oil here, correct?

The gas in the model is assumed to be wet-gas, it does have some liquid in it. The oil type is live oil and there is no gas cap (Pi >Pb) at the initial conditions.

It is hard to say what is causing this without a test deck, but I think the problem is related to the scaling, and not the equilibration, I suspect that scaling is creating grid blocks with zero mobile oil or zero mobile water.

Please check this test case: SPE_relperm_scale.DATA.zip It does not create the exact errors I get with the full model, but it should be close enough.

[OPMUSER]

I don't think this is the problem; but OIL, GAS, WATER, VAPOIL and DISGAS phases are declared in the RUNSPEC, seems strange as you only have a saturated oil and therefore there is no VAPOIL (or condensate in the model). Once the gas is liberated from the oil, that gas has zero liquid. We are not dealing with a gas cap (you said unsaturated oil) or volatile oil here, correct?

It is hard to say what is causing this without a test deck, but I think the problem is related to the scaling, and not the equilibration, I suspect that scaling is creating grid blocks with zero mobile oil or zero mobile water. I say this because the Sw points are being scaled up but the Sorw is being taken from the relative permeability tables. So check the SWL, SWCR, SWATINIT, SORW, and PC arrays in both the Eclipse and OPM Flow runs.

Also do you see very large values of Pc in the Eclipse version?

[OPMUSER]

Thank you for the test deck. There was a couple of errors in this deck, one was the SWATINIT array was incomplete, so I used the SWL as SWATINIT. Secondly, the injector was declared a gas injector when it was actually injecting water, I therefore changed the injector to a water injection well. Neither of these errors were caught by OPM Flow.

I notice that some of the SWATINIT/SWL values are zero, @bska will this cause a problem, especially zero values for SWATINIT in active cells? Note also that there is communication between the various PVT regions, which will not help convergence.

The next thing I tried was switching off all the wells and setting TSTEP to be:

TSTEP
2*0.00001 /

Just to see if I could get a solution to examine the results, but instead got this:

Failed to create valid EclipseState object.
Exception caught: Times added must be in strictly increasing order.
terminate called after throwing an instance of 'std::invalid_argument'
  what():  Times added must be in strictly increasing order.
Aborted (core dumped)

So I changed to:

TSTEP
2*0.001 /

I then got this:

================ Starting main simulation loop ===============

Report step  0/2 at day 0/0.00199074, date = 01-Jan-2015

Time step 0, stepsize 0.00099537 days.

Problem: Solver convergence failure - Iteration limit reached
Timestep chopped to 0.000328 days

Time step 0, stepsize 0.000328472 days.

Problem: Solver convergence failure - Iteration limit reached
Timestep chopped to 0.000108 days

Time step 0, stepsize 0.000108396 days.
Time step summary: newton its =  2, linearizations =  3 ( 0.003 sec), linear its =   2 ( 0.001 sec)

Time step 1, stepsize 0.000216792 days.
Time step summary: newton its =  2, linearizations =  3 ( 0.006 sec), linear its =   2 ( 0.001 sec)

Error message: ecl_smspec_fwrite: Unable to open fortio file (null), error: Bad address .

See file: /tmp/ert_abort_dump.david.20190224-143204.log for more details of the crash.
Setting the environment variable "ERT_SHOW_BACKTRACE" will show the backtrace on stderr.
Aborted (core dumped)

So I still cannot check the SCAL arrays for inconsistent values, and I'm not sure that we have duplicated the original error.

[joakim-hove]

For the last problem - try to give the deck a valid ALL_CAPS name

[OPMUSER]

That solved the last problem, thanks @joakim-hove.

The journey continues

[OPMUSER]

Okay, a few things OPM Flow does not appear to write out the SWATINIT and the end point arrays to the INIT file, or they are not listed in the STATIC Result Property list in ResInsight.

This test model has lots of cells with SOIL=1.0, SGAS =0.0 and SWAT=0.0; thus is it the SWAT=0.0 causing the problem? if it is then we should trap this.

[ghost]

@OPMUSER & @joakim-hove I'm really sorry for the naming error. I renamed the file just before sharing it and did not realize it would be a problem.

[ghost]

There was a couple of errors in this deck, one was the SWATINIT array was incomplete, so I used the SWL as SWATINIT.

Do you mean the grid cells with defaulted SWATINIT vaules? This also seemed strange to me as well, but this is the orginal format for SWATINIT array that was generated by Petrel. I included it in the test case as it is to see if this leads to an problem in Flow.

Secondly, the injector was declared a gas injector when it was actually injecting water, I therefore changed the injector to a water injection well.

Sloppy copy-paste job on my side.

[OPMUSER]

I assume that Petrel exported the 1* as the cell was made inactive by the ACTNUM keyword, or any other variable that makes the PORV zero.

SWATINIT
-- 10*0 1* 1* 15*0 7* 0 0 0 0.733043 83*0 13* 7*0 13* 0.794119 
-- 0.719561 0.667237 0.625999 77*0 37* 0.790661 0.699081 0.654646
--  0.630778 0.62801 0.630247 0.645663 0.675409 74*0 35* 0.867333 
--  0.727738 0.666677 0.661007 0.670058 0.668246 0.665272 0.683148 
--  0.705607 0.703205 0.698905 /
-- 
-- MISSING SWATINIT VALUES SO USE SWL
--
10*0 1 1 15*0 7*1 0 0 0 0.733043 83*0 13*1 7*0 13*1 
0.794119 0.719561 0.667237 0.625999 77*0 37*1 0.790661 
0.699081 0.654646 0.630778 0.62801 0.630247 0.645663 
0.675409 74*0 35*1 0.867333 0.727738 0.666677 0.661007 
0.670058 0.668246 0.665272 0.683148 0.705607 0.703205 
0.698905 /

There should be 400 values for SWATINIT, but there are lots of zeros as well. If the blocks are not active then that is okay, but if they are active that could be the cause of the problem.

[ghost]

I see. Yes, there are a considerable amount of cells that are inactive in the model. But, even using SWL values in SWATINIT array does not seem to solve the problem.

[OPMUSER]

Yes, that is because there are some SWL values that are equal to zero as well, so we still get SWATINIT values of zero.

[ghost]

I tried adding 0.01 to grid cells with 0 in SWATINIT array to check, but still doesnt solve it.

[ghost]

@OPMUSER Just wanted check if you were able to figure out what is the problem regarding this issue and a possible way forward?

[OPMUSER]

Not really as OPM Flow 2018-10 is not writing out the SWATINIT array or the endpoint array data so it is really difficult to see what is causing the problem. I have reported this issue in #1738. However, as you can see from the following figure:

The initialize water saturation from OPM Flow (right) matches the SWATINIT of both OPM Flow and Eclipse (left). But when you compare both model's initialized SWAT arrays they are different

So it appears that OPM Flow is honouring the SWATINIT array throughout the model and Eclipse is honouring the SWATINIT and endpoint/relative permeability data above the OWC in the test case. @bska and @crayxt are the developers aware of this, as this will be an interesting discussion ;-)

That being said, if NTG gross cut-offs have been applied (and they should be applied) then these high water blocks should be made in active above the OWC. So for an evening opportunity, set all grid blocks above the OWC that have SWATINIT values equal to 1.00 to being inactive, and see if that resolves the problem.

I'm not sure this will fix your problem, as we we are looking at a test case but it is worth a try.

[OPMUSER]

Not really as OPM Flow 2018-10 is not writing out the SWATINIT array or the endpoint array data so it is really difficult to see what is causing the problem. I have reported this issue in #1738. However, as you can see from the following figure:

The initialize water saturation from OPM Flow (right) matches the SWATINIT of both OPM Flow and Eclipse (left). But when you compare both model's initialized SWAT arrays they are different

So it appears that OPM Flow is honouring the SWATINIT array throughout the model and Eclipse is honouring the SWATINIT and endpoint/relative permeability data above the OWC in the test case. @bska and @crayxt are the developers aware of this, as this will be an interesting discussion ;-)

That being said, if NTG gross cut-offs have been applied (and they should be applied) then these high water blocks should be made in active above the OWC. So for an evening opportunity, set all grid blocks above the OWC that have SWATINIT values equal to 1.00 to being inactive, and see if that resolves the problem.

I'm not sure this will fix your problem, as we we are looking at a test case but it is worth a try.

[OPMUSER]

Update, I tried exporting the Eclipse SWAT array, renaming it to SWATINIT and loading it into OPM Flow. OPM Flow runs but it fails to convergence after 10 time step cuts.

Time step 0, stepsize 1.53158e-05 days.
    Switching control mode for well PROD from SURFACE_RATE to BHP
    Switching control mode for well PROD from BHP to SURFACE_RATE
    Switching control mode for well PROD from SURFACE_RATE to BHP

Error: Solver failed to converge after cutting timestep 10 times.

Error: Program threw an exception: [/build/opm-simulators-zxOdi_/opm-simulators-2018.10-rfinal/opm/simulators/timestepping/AdaptiveTimeSteppingEbos.hpp:349] Solver failed to converge after cutting timestep 1

Taking a look at the used SWATINIT array shows lots of small negative values, including a zero value.

-- Exported from ResInsight
SWATINIT
      0.00626155     -1.3395e-05    -2.64393e-08    -1.00897e-08    -7.37688e-09               
     -7.9043e-08    -3.76511e-08    -2.28662e-08    -2.14494e-08    -1.88876e-08               
        0.650126        0.650239    -1.19949e-06     6.74163e-07     1.52034e-06               
     1.09888e-06    -4.11477e-08    -3.85308e-08    -8.20273e-08     -9.9379e-08               
    -6.76727e-08    -7.61988e-08    -1.93547e-07    -8.96908e-08    -3.28939e-08               
     1.54037e-07     1.12448e-07        0.651367        0.651344        0.651343               
        0.651332        0.651338        0.651341        0.651341    -3.63507e-08               
    -3.21705e-07    -2.35917e-06         0.69377    -2.29618e-06    -2.33576e-06               
    -8.52595e-08      1.2407e-06     1.86404e-07    -9.08031e-07    -3.02447e-06               
    -6.84417e-06    -8.05378e-06    -7.94131e-06    -8.26311e-06    -7.71908e-06               
      2.5743e-06     1.53094e-06    -1.14108e-06    -3.88584e-06    -7.56836e-06               
    -9.22559e-06    -8.98876e-06    -8.80957e-06    -7.86643e-06     -8.1661e-06               
    -2.72339e-07    -1.80638e-06    -3.60013e-06    -5.76746e-06    -8.19462e-06               
    -9.78648e-06    -9.25535e-06    -9.17893e-06     -9.6244e-06    -9.84952e-06               
    -2.42433e-06    -4.84024e-06    -5.51385e-06    -7.94768e-06     1.35299e-05               
     3.57677e-05     3.24733e-05     2.94672e-05     1.58472e-05    -9.40183e-06               
     4.42204e-05     4.19297e-05     3.81999e-05     3.24714e-05     1.64741e-05               
     6.15953e-06     4.46135e-06     6.27321e-06     1.40305e-05     2.88635e-05               
    -1.30175e-09    -7.78158e-10     9.54228e-10    -7.55624e-09    -8.15101e-09               
    -9.84891e-09    -1.06331e-08    -9.15754e-09    -4.39484e-09    -2.38035e-10               
               0    -2.15545e-05    -3.02489e-08    -1.15159e-08    -8.41066e-09               
    -9.07155e-08    -4.30778e-08    -2.61647e-08    -2.45303e-08    -2.15905e-08               
      0.00677967        0.006886    -1.26641e-06     9.47744e-07     1.98954e-06               
     1.59024e-06     4.02026e-07     1.82083e-05     1.81018e-05     1.81736e-05               
      9.7644e-06        0.651293        0.651304        0.651309        0.651296               
        0.651299        0.651318        0.657469        0.657402        0.657401               
        0.657373         0.65739        0.657395        0.657394     3.61424e-05               
       0.0111422       0.0111857       0.0262961       0.0111955       0.0111622               
       0.0111364        0.658201        0.658212        0.658213        0.658173               
        0.658196        0.658218        0.658246        0.658213        0.658212               
        0.658215        0.658221        0.658218        0.658184        0.797023               
        0.725931        0.672506        0.632222       0.0111554       0.0111447               
       0.0111527        0.011151       0.0111431        0.011154       0.0111984               
       0.0111407       0.0111486       0.0111502       0.0111477       0.0111507               
       0.0111349       0.0111262       0.0174478      0.00732803       0.0025971               
     0.000236974     0.000208221     0.000224813      0.00145498      0.00464362               
     5.02861e-05     4.76816e-05      4.2124e-05     3.71541e-05     1.88811e-05               
     7.05569e-06     5.11097e-06      7.1853e-06      1.6074e-05     3.30421e-05               
    -1.45072e-09    -6.45136e-10     1.27979e-09    -8.40235e-09     -9.0739e-09               
    -1.10236e-08     -1.1924e-08    -1.02349e-08     -4.7784e-09    -3.46738e-11               
     0.000286838     0.000293976     0.000299619     0.000299737     0.000291474               
     0.000299575     0.000300326     0.000300489      0.00030056     0.000300586               
      0.00027543     0.000285428     0.000302433     0.000301524     0.000301416               
     0.000300074     0.000299723     0.000302069     0.000301939     0.000301934               
     0.000306849     0.000291182     0.000289874     0.000289202       0.0002867               
     0.000288061     0.000290109     0.000277257     0.000277153     0.000277042               
     0.000277846     0.000278653     0.000278879     0.000276932      0.00030417               
        0.713423        0.713525        0.719689        0.713539        0.713469               
        0.713379        0.715874        0.715902         0.71591        0.715796               
        0.715884        0.715945        0.716018        0.715941        0.715938               
        0.715936        0.715947         0.71594        0.715822        0.718923               
        0.716333        0.716817        0.716243        0.713476        0.713453               
        0.713455        0.713454        0.713445        0.713467        0.713339               
        0.713384        0.713447        0.713466        0.713463        0.713472               
         0.71342         0.71341        0.780494        0.694742        0.653197               
        0.630859        0.628107        0.630332        0.644934        0.672762               
     0.000298121      0.00029801     0.000294343     0.000299507     0.000301196               
     0.000300496     0.000300336     0.000300459     0.000301488     0.000299867               
      0.00029838     0.000297933     0.000297428      0.00029875     0.000299648               
     0.000299761     0.000299784     0.000299803      0.00029989     0.000300346               
         1.00001        0.999986               1               1               1               
               1               1               1               1               1               
        0.999964        0.999994        0.999999               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1        0.999998               1               1               1               
               1         1.00001         1.00001         1.00001         1.00001               
        0.999998        0.999999               1               1               1               
               1               1         1.00001         1.00001         1.00001               
               1               1               1               1         1.00001               
         1.00001         1.00001         1.00001         1.00001         1.00001               
               1         1.00001         1.00001         1.00001         1.00002               
         1.00003         1.00002         1.00002         1.00002         1.00001               
         1.00002         1.00002         1.00002         1.00002         1.00001               
               1               1               1         1.00001         1.00002               
        0.999999        0.999999        0.999999        0.999999        0.999999               
               1               1               1        0.999999        0.999999               

               /               

So I think this is a data issue and Eclipse is more forgiving compared to OPM Flow.

[ghost]

That being said, if NTG gross cut-offs have been applied (and they should be applied) then these high water blocks should be made in active above the OWC. So for an evening opportunity, set all grid blocks above the OWC that have SWATINIT values equal to 1.00 to being inactive, and see if that resolves the problem.

Looks like you are right about applying NTG cut-offs. The full model does contain NTG cut-off for each grid cell. By adding NTG to the test case (SPE_RELPERM_NTG.DATA.zip), the the test case does run. However, the timestep size is too short for convergence on Flow (for TSTEP 1/ I got Total time (seconds): 62.2412). Total cpu time with Eclipse is 0.21 seconds for comparison.

[OPMUSER]

Are there still negative water saturations in the SWAT array?

[ghost]

No, there are no negative values in the SWATINIT array. The attached deck to my previous comment produced this on Eclipse:

-- Exported from ResInsight
SWATINIT
               0               0               0               0               0               
               0               0               0               0               0               
               1               1               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               1               1               1               
               1               1               1               1               0               
               0               0        0.733043               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               0               
               0               0               0               0               0               
               0               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1        0.794119               
        0.719561        0.667237        0.625999               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1        0.790661        0.699081        0.654646               
        0.630778         0.62801        0.630247        0.645663        0.675409               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               0               
               0               0               0               0               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1               1               
               1               1               1               1        0.867333               
        0.727738        0.666677        0.661007        0.670058        0.668246               
        0.665272        0.683148        0.705607        0.703205        0.698905               

               /               

[OPMUSER]

Well an interesting Sunday afternoon. What I did was to take your latest case and write an Octave script that extracts all the endpoint data in ResInsight for each grid block to see what was going on.

OPM-PROPERTIES-DBG-01-DEBUG.ods.zip

As you can see, there are lots of cells with SWATINIT equals 1.00 and where the commercial simulator appears to set the water saturation 1-SOWCR from the relative permeability curves. As I stated above:

The initialize water saturation from OPM Flow (right) matches the SWATINIT of both OPM Flow and Eclipse (left). But when you compare both model's initialized SWAT arrays they are different

Thus, I think this is what is going on and why the commercial simulator runs and OPM Flow does not, that is the two simulators initialize the model differently when there is conflicting input data . I cannot prove this, as OPM Flow does not write out the endpoint data to the INIT file for me to check.

If you want to use OPM Flow, you could using the commercial simulators SWAT array as your SWATINIT array and see if the works (you can export the array from ResInsight). You could also try exporting both the SWAT, PRESSURE, RS and RV arrays and see if that works, never tried this myself.

[ghost]

If you want to use OPM Flow, you could using the commercial simulators SWAT array as your SWATINIT array and see if the works (you can export the array from ResInsight).

For some strange reason, ResInsight is indicating that there is no recorded Dynamic data, even if the case is run on commercial simulator:

[OPMUSER]

That is because the run never completed the first time step, as the wells have no completions. Insert a time step before the WELLSPECS keyword or comment out all the well data keywords.

[ghost]

That is because the run never completed the first time step, as the wells have no completions. Insert a time step before the WELLSPECS keyword or comment out all the well data keywords.

Thanks for the tip. But still dont get any dynamic data array in ResInsight (v. 2018.11.2). I modified the SCHEDULE section as:

SCHEDULE
---------------------------------------------------------------------------
RPTSCHED
    'PRES' 'SGAS' 'RS' 'WELLS' /

--WELSPECS
--  'PROD'  'G1'    10  10  1*  'OIL' /
--  'INJ'   'G1'    1   1   1*  'WAT' /
--/

--COMPDAT
--  'PROD'  10  10  3   3   'OPEN'  1*  1*  0.5 /
--  'INJ'   1   1   1   1   'OPEN'  1*  1*  0.5 /
--/

--WCONPROD
--  'PROD' 'OPEN' 'ORAT' 20000 4* 1000 /
--/

--WCONINJE
--  'INJ'   'WAT'   'OPEN'  'RATE'  100 /
--/

TSTEP
10*365 /

END

I even added COMPDAT data to the wells, so that the summary file curves can be plotted. But, there is no dynamic data. Can you please share the SCH section your DATA file ?

[OPMUSER]

The job will not run because of numerical errors, I just changed the time step to one day to get some results to see the endpoint data in ResInsight. And as mentioned above there are inconsistencies that cause OPM Flow and Eclipse to have different SWAT arrays. This may or may not be a bug in OPM Flow. ECL_SPE_RELPERM_NTG#1.zip The OPM Flow run file and results are in this file OPM_SPE_RELPERM_NTG#1.zip The concern is that the test example has lots of consistencies which may be not be representative of the original problem.

I do think it would be better to work with the original model, or a subset of it to really find out what is happening. For example, trying creating an LGR in ResInsight and building and testing a subset of the model.

I am travelling the next couple of days, so will be unable to respond in a timely manner.