Mistmatch for Egg model about flownet

[tayloris]

I'll include the relative's permeabilities in the next try

[tayloris]

So after several discussions, we found that that observation uncertainties were high for the egg model. In this regard, the solution is to decrease the values of the hard-coded observation uncertainties in files observations.yamlobs.jinja2 and observations.ertobs.jinja2. This observation uncertainty parameter will be soon added as an input parameter in the configuration file.

The history match has better quality now as you see

[anders-kiaer]

@tayloris How many realizations went into the run? Or did you mean "40 realizations" instead of "40 ensembles"? Would be interesting to see iter-0 as well in the same plot, to see initial span/coverage (but I do not think FlowNet automatically includes that in Webviz... so maybe we should add the first iteration as well on general basis)

[wouterjdb]

Was just thinking the same: how does iter-0 look like? If you see that there is coverage then it looks like the ensemble has collapsed during the history matching process. This can potentially be mitigated by increasing the number of realizations. How many observations and uncertain parameters (the ones you're matching) do you have?

[tayloris]

Here, is the figure with the first and last iteration, 7 iterations in total, 40 ensembles and 100 extra nodes. We are using all observation for egg model, the whole simulation time as a data set. And all the parameters for the fluid and the rock(perm, poro, bluk modulus). I'll try to increase the number of realizations.

[tayloris]

Here, I reduce the number of parameters. Parameters related to relative permeabilities are fix to the one for the egg model. So It calibrates permeability porosity and bulk modulus. It runs 100 realizations on 6 iterations with zero additional nodes.

[wouterjdb]

Here, I reduce the number of parameters. Parameters related to relative permeabilities are fix to the one for the egg model. So It calibrates permeability porosity and bulk modulus. It runs 100 realizations on 6 iterations with zero additional nodes.

Seems like you're getting closer!

[tayloris]

In this next figure, I show the results, using the same setting as the previous figures but with 20 additional nodes. The gap between data and prediction increase a bit.

[wouterjdb]

Could it be that, by increasing the number of nodes, you increase the number of parameters to match. So one also needs to increase the number of realization accordingly (with some number).

[tayloris]

In this figure, I include 500 realizations. Still, I see a consistent gap. I'm not including relative permeabilities parameters. It has 20 additional nodes.

[wouterjdb]

What do you mean with not including relative permeability parameters? You are looking at water/oil rates, so relative permeability rather important for that.

How does you pressure match look like now?

[tayloris]

Yes, I just wanted to reduce the number of parameters, The pressure has big range so maybe I should reduce the range in permeability

[wouterjdb]

Seems like you have a bit of tuning to do yeah - if you could share your fork/branch for the Egg model it makes it a bit easier to look at what you have as input (and maybe run it here myself).

[tayloris]

Here you have, https://github.com/tayloris/flownet/tree/Egg_Model_Config . Inside examples folder you have a zip folder with all simulations results from OPM/Flow if need it.

[wouterjdb]

I had a quick initial look. Some thoughts:

• Permeability: The permeability in the Egg model is from 53.9 mD up to 7000 mD, with an average of more than 1000 mD. The minimum in the config is 1 mD and maximum is 5000 mD, with a loguniform distribution (the is the default). I'd suggest to change your prior to 10 mD - 10 D, and verify that the average permeability in the model fits what you are trying to match. If it is too low, you could increase your lower range or, depending on the distribution in the original model, change your distribution to uniform (that will make your entire model quite permeable, and much more homogeneous. But this might fit the Egg model? Not sure, haven't checked in detail. I observed very few <100 mD when scrolling through the data deck). Playing with this parameter will have a significant impact on your pressure match.

• Porosity: The porosity in the Egg model is fixed at 20%. Your range is 5-50%. I'd suggest to lower the upper range from 50% to 30%. (The theoretical maximum porosity for a cubic packed rock is 47.6%, see this link).

• Rock compaction: You have two zero values in your config. Not sure if this will work correctly; maybe your maximum should be slightly larger (as you have done for EQUIL). Maybe you could just remove the entire entry for rock compaction: this should work. If not: it's an issue to fix.

• Relative permeability: The global scheme as you have is OK, as there is only one relative permeability used in the Egg model. I haven't checked whether your relative permeability curves look OK though - have you ever plotted the generated curves on the Egg model curve? This is particularly important for getting a decent phase match.

• Ensemble weights: There is only the weight '1' in your config. You should do more ES-MDA iterations, for example 6 or so.

• Aquifer: I see that AQUDIMS is defined in the Egg Model deck. I didn't see any further aquifer definitions - does the model have an aquifer at all? If not, maybe it could be good to also remove it from the FlowNet model and just play with the bulk volume multiplier (another option could be to allow for very small aquifer size, such that they don't matter much. But, check that there is really no aquifer, I might have missed it!). Volume, aquifers and the bulk_volume_multiplier, will have a significant impact on your pressure match.

• Realizations: There is a relatively low number in the config - but you already said you used more. I'd suggest a number of 100-200 for your initial testing. Depending on the number of parameters you might need many more though.

• max_running: You have set this to 4; you might get away (depending on your computer). Even though you might not have more CPU's, I think that due to IO waiting in processes, you can still get improvements in total runtime.

Mind that what I wrote above are just some suggestions/thoughts based on that I looked at the model deck, I didn't inspect the Egg model in detail. Neither did I yet run the model. I hope it helps somewhat.

[tayloris]

Hi Wouter

Many thanks for the detailed review.

I'll make two issues regarding the rock-compressibility and Aquifer section. Flownet gives an error when they are not defined.

Permeability: Yes, a long-range of permeability cause a long-range of pressure drop in the ensembles.

Rock compaction: The configuration parse sett rock-compressibility as "required" so it gives an error if is not define in the config file. I'll make an issue about it

Relative permeability: I have not plotted it but here you can see the tables from the egg model and the table generated by pyscal.
Both tables are identical except for the last row where SW is 0.9 for egg model and 1.0 for the one generated by pyscal.

Ensemble weights: Yes, for all the figures I reported I used usually 6 iterations.

Aquifer: There is not Aquifer defined in EGG model. When I removed it gives me an error, so I'll create an issue about it.

Realizations: Yes, for most of the figures I reported I used usually 200 realizations.

Original SWOF table from Egg model
SWOF​
0.1000, 0.0000e+00, 8.0000e-01 0​
0.2000, 0.0000e+00, 8.0000e-01 0​
0.2500, 2.7310e-04, 5.8082e-01 0​
0.3000, 2.1848e-03, 4.1010e-01 0​
0.3500, 7.3737e-03, 2.8010e-01 0​
0.4000, 1.7478e-02, 1.8378e-01 0​
0.4500, 3.4138e-02, 1.1473e-01 0​
0.5000, 5.8990e-02, 6.7253e-02 0​
0.5500, 9.3673e-02, 3.6301e-02 0​
0.6000, 1.3983e-01, 1.7506e-02 0​
0.6500, 1.9909e-01, 7.1706e-03 0​
0.7000, 2.7310e-01, 2.2688e-03 0​
0.7500, 3.6350e-01, 4.4820e-04 0​
0.8000, 4.7192e-01, 2.8000e-05 0​
0.8500, 6.0000e-01, 0.0000e+00 0​
0.9000, 7.4939e-01, 0.0000e+00 0​

Table generated by Pyscal with parameters from egg model.

[wouterjdb]

As a result of stepping into this pitfall we decided to make sure that the step of setting the observation error will be exposed more clearly to the user, see issue #120. As the described problem in this issue is solved I'll close the issue.