THERMAL mode different results in v2020.04 and v2022.04

[nikovanderpost]

dear community,

whilst recently upgrading to OPM flow 2022.04, I noticed that attached Thermal deck showed a markedly different temperature front compared with the same deck as run in the previous version I used, 2020.04. See e.g. a grid block water viscosity versus time for the old (2020.04) and new (23NOV22, run in 2022.04) run, exactly the same deck, attached below.

With the 2020.04 version showing pretty good matches with analytical calculations and DoubletCalc 2D, I suspect there is an issue in 2022.04 (and also 2022.10).

Thanks, Niko van der Post

VOLDUM3_5_BASE.DATA.txt

[goncalvesmachadoc]

Hi, Niko. Thank you for reporting it. At first look, I see you are trying to simulate a geothermal doublet. For that you could use a single-phase model (THERMAL + WATER only). That may speed up your calculations and prevent any issues that may arising for having dummy phases in the model, besides simplifying the input data. I see also you have just very few coarse grids between the two wells, numerical dispersion can become considerable and difficult to compare with analytical results. Will go ahead and run the case with both OPM versions and do some further investigations.

[bska]

In addition to @goncalvesmachadoc's comment, I'll also note that thermal simulations are under active development and are likely to not be as mature as the rest of the simulator. That said we recently (16th November) released the 2022.10 version of the simulator and if at all possible I would invite you to try that version too. For what it's worth, I get the results below when running your model on my local development machine. I tried both a sequential (_SEQ_R2022-10) and a parallel (_NP14_R2022-10) run as well as a sequential run using the latest development sources of the simulator (_SEQ_DEV). The fact that the parallel results differ this markedly from the sequential run is a little disconcerting and points to a deeper issue. I'm also a little worried that the results from the development sources don't match either of the 2022.10 release runs.

---

[nikovanderpost]

Dear Cíntia and Bård

thanks for your replies. A few clarifications

• I agree that running in water only mode is better, great improvement and thanks for that Cíntia. Single phase was not possible in 2020.04 but I now do it standard in 2022.04. Note 3 phase and 1 phase perfectly overlap in 2022.04, so this is not the reason for the 2022.04 and 2020.04 discrepancy.
• agree about the numerical dispersion, and I tested this to get to a "reasonable" grid block size. I have also tested the runs with smaller grid blocks (> 10 blocks between inj and prod) and the 2022.04 and 2020.04 discrepancy is still there.
• with regard to parallel runs: this I never do in thermal mode because I noticed inconsistencies: running with mpirun -np 4 yields multiple Z layers with different permeabilities to have the same temperature front...

Let me over the next days mimic a simple 2D problem in one phase with high resolution (no overburden) and see whether I can get it to match Doubletcalc2D.

Yours, Niko

[nikovanderpost]

Now I have run a simple model in DoubletCalc2D without overburden, NTG=1 and without aquifer, and inject and produce 156 m3/h.

The same case is modelled in OPM flow 2022.10, and after 5 y injection the temperature profile away from the injector compares as below.

If anyone still has flow -v 2020.04 it would be interesting to run attached .DATA file because I suspect results will be different, better matching DoubletCalc2D.

Yours, Niko van der Post

Runs25nov22.zip

[totto82]

I have tested the first model you shared with 2020.04 and current master I are able to reproduce your first plot. I added screenshots showing temperature in 2056 for both simulations. Seems like the cold front is evolving faster in 2022. Will do some debugging to see if I understand what happened between 2020 and 2022 that can effect the thermal simulations.

Results (master)

Results(2020.04)

[nikovanderpost]

Thanks Tor.

Once we have some more clarity I am happy to do a few comparisons with DoubletCalc2D and analytical calculations to improve our confidence.

Yours, Niko

[totto82]

I have compared relevant 2020 and 2022 code without noticing anything suspicion. We added a fix for the thermal conductivity, but that does not effect your test case it seems. Based on looking at your curve it seems like something goes wrong with the rock heat capacity. Dividing it with 0.3 (one feet) gets the results much closer to the analytical solution. (i.e. SPECROCK 134 not 40.3). Maybe you could make a test case in Metric units, that will make the comparison with the analytical solution easier and also reduce issues related to unit conversion.

[nikovanderpost]

Over the weekend I have made a couple of runs following your suggestions, with my conclusions in italic. I did quite some grid size sensitivities, but these are not too important.

• Running the 2D model without overburden in METRIC 2022.10, leads to a reasonable match with DoubletCalc2D. When running in FIELD units, some conversion goes wrong, most likely in SPECROCK since without the overburden this model is not sensitive to heat conduction THCONR
• Introducing an overburden in this METRIC model, I have put the reservoir layer at 10C and injecting at 10C, and the overburden at 69C. I then calculate analytically the temperature development versus time 25 m above the top injector (black line), using Green and Willhite EOR eq. 8.53. I need to increase THCONR with a factor 3.1 to come close to a match. Some conversion issue also exists in the METRIC deck, for THCONR
• When running METRIC with this 3.1 THCONR multiplier, I still do not get the old 2020.04 FIELD results. Apparently there is another issue still present

This is how far I could get the forensics. I propose to handle the outcomes of the 2022.10 thermal model with care.

[totto82]

@nikovanderpost Do you mind sharing the metric model as well. That should help the debugging.

[nikovanderpost]

pls find attached the DATA file of the metric model, both without overburden (so matching the DoubletCalc model) and with overburden, testing THCONR. Excel with results and analytical calcs also included.

Niko

15dec22.zip

[totto82]

I have look for bugs related to FIELD and METRIC conversion but didn't find any other than that there is some differences between DOUBLET2D_TEST_NO_OB_1D_NOFLOWBOUND_METRIC_V2.DATA from 15dec22.zip and DOUBLET2D_TEST_NO_OB_1D_NOFLOWBOUND_.DATA from Runs25nov22.zip

Most notably the well rates are different towards the end of the simulations. After correcting the well rate in the FIELD model the simulations agree reasonably well. Also with the analytical solution. Adding more digits to make the conversion more accurate in the deck and adding the missing ROCK keyword in the _METRIC case further made the results more the same. My conclusion is that there are no conversion issues in the simulator.

I will continue to look into the difference between the old release and the current master. That is probably another issue.

[nikovanderpost]

Dear colleagues, I have done a few more checks on v2022.04, notably:

• compare a 1 D cold water flood between ECL100 TEMP and OPM flow THERMAL, no convection.
• made a simple 1D convection only (so no flow) model and compare this to analytical calculations

Both tests match very well. This makes me conclude that the current OPM Flow thermal simulation can be trusted, however without understanding the discrepancies with the 2020-04 version.

Niko