Improve consistency for SWCR

[alifbe]

There are two issues that potentially create inconsistency Swcr (critical saturation)

1. Precision of relative permeability generated by pyscal. In this example, pyscal reported Swcr = 0.057 but from the table we see that it should be 0.064 since it's the largest Sw where krw is zero. (It is zero due to precision of pyscal output)
2. From this table, Eclipse will pick 0.084 as Swcr since its criterion for zero is less than a threshold value which by default is 1.0E-6 (E100/Flow) and 1.0E-20 (E300)

SWOF
-- SCAL recommendation interpolation to 0.5
-- SATNUM 1 
-- pyscal: v0.12
-- swirr=0 swl=0.044 swcr=0.057 sorw=0.239814
-- krw = krow @ sw=0.56776
-- SW     KRW       KROW      PC        
0.0440000 0.0000000 1.0000000 10.8329040
0.0540000 0.0000000 0.9893945 6.8304541
0.0570000 0.0000000 0.9854823 6.0474202
0.0640000 0.0000000 0.9752507 4.6588961
0.0740000 0.0000002 0.9588309 3.3596226
0.0840000 0.0000008 0.9406121 2.5253604
0.0940000 0.0000021 0.9207817 1.9602723
0.1040000 0.0000043 0.8994980 1.5611378

[bartekvik]

You may also want to include the issue that was reported in connection with the non-monotone Pc-curve, as it appears to be related to the same underlying problem.

[bartekvik]

One potential part of the solution for this issue would be to override the saturation step length (--delta_s) to ensure that the parameters remain monotonic while still maintaining a precision level consistent with standard Eclipse/OPM Flow input.

[berland]

1. Precision of relative permeability generated by pyscal. In this example, pyscal reported Swcr = 0.057 but from the table we see that it should be 0.064 since it's the largest Sw where krw is zero. (It is zero due to precision of pyscal output)

I reckon this is ok. Pyscal reports swcr=0.057 because that is what is uses to construct the curve. Then due to the numerical input in curve shape, the values become less than the printed accuracy, leading to an effective swcr slightly higher.

2. From this table, Eclipse will pick 0.084 as Swcr since its criterion for zero is less than a threshold value which by default is 1.0E-6 (E100/Flow) and 1.0E-20 (E300)

That is the best Eclipse can do from the data it gets yes. Alternatively, Eclipse would have to support more decimals, and calculate with KRW values in the range 10^-15 to 10^-8 from swcr=0.057, which should not yield any observable difference in the Eclipse simulation results.

[bartekvik]

The chosen precision and resulting rounded values do not lead to any observable differences in Eclipse simulation results for the original (unscaled) input. However, the impact becomes more evident for the oil relative permeability start point for scaled curves, as illustrated in Figure (3‑point scaling in this case). This behaviour is related to Eclipse’s handling of scaling, but increasing the numerical precision would eliminate the scaling issue.