Closed system geothermal model not timestepping

[EdmundStephens]

[v2023.04] Please can you help me get this model running. I am trying to model a closed system geothermal producer. The system is a 500 m thick type 1 fractured basement (i.e. single porosity) at around 4000 m depth at initial 183 deg C. The scheme to test is for cold water is to be injected into the annulus and produced up the tubing. Since as far as I can tell there is no thermal well inflow model I am explicitly representing the tubing volume, tubing wall, annular volume and casing / cement as concentric grid cells, thereby modelling the heat flow explicitly in the block-block calculations.

Convection of fluids in the reservoir is key, which depends on Kv and temperature dependence of the water density (like a chimney) thus greatly enlarging the thermal drainage radius and stable heat extraction rate. I am hoping to see the impct of WATDENT in the model which is not implemented in E100 or black oil tNav.

Attached is the model

• Grid_Log1 ... grid definition & output (in FILL)
• H1 ... E100 model including summary, grid and results output
• H1f ... equivalent model in Flow which loads Ok but does not time step

Temperature drop around the well bore at t=1 year:

Grid_Log1.zip
H1.zip
H1f.zip

[totto82]

Please can you help me get this model running

I tested the H1f model and it complains about GCONTOL and COORDSYS not supported. You can either remove those keywords or run with --parsing-strictness=low, which will ignore those keywords.

I notices that some wells starts to shut during the simulations so you may need to do some tuning to avoid this. Note that Flow ignores the TUNING keyword in the deck ((as default) and instead depend on input parameters.

[EdmundStephens]

Yes indeed I used --parsing-strictness=low, attached the .param file for this run.
H1f_param.zip

The temperature solution seems to be quite exacting on the solver, since there is virtuallly no pressure change, material balance or fluid flow ... this is also the case in Eclipse and tNav and seems to be fixed by decreasing the time step sizes and some of the tolerances particularly on material balance. (Note those tools do not implement WATDENT which is critical for convection). The following are in my .param file, but perhaps you can improve the solver reliability?

time-step-control-target-iterations=12
time-step-control-target-newton-iterations=5
time-step-control-tolerance=0.1
time-step-verbosity=1
tolerance-cnv=1e-02 #1e-02
tolerance-cnv-relaxed=1
tolerance-mb=1e-10 #1e-06
tolerance-pressure-ms-wells=1000
tolerance-well-control=1e-05 #1e-07
tolerance-wells=1e-03 #1e-04

[totto82]

Try using
--use-gmres=true

that worked fine for me combined with
--linear-solver=cpr
--tolerance-mb=1e-8

[EdmundStephens]

Thanks for that, however still not working ... I tried the .param settings but no luck. I had gmres=true and tied both cpr and cprw linear solvers. (For context, I am using Flow via Ubuntu WSL in Windows 10).

Attached my revised run including PRT outputs for the H1f case.
H1f (cpr,gmres).zip

I also made a radial model of the same case and see the same non-convergence in that case
Eclipse case (no WATDENT): H1R.zip
Flow v2023-04: H1Rf.zip

These just back up and stop after 10 timestep reductions. I am using 2023-04 still, perhaps this will work better in the upcoming 2023-10 release?

[EdmundStephens]

Resolved, this was the setting that ended up blocking the solver.

temperature-max=300 #1e+09

works when restored to default

temperature-max=1e+09

This at least time steps, I'm comparing what comes out and will test if it makes sense. Some of the runs show a runaway production temperature (up to 1000 deg C) which looks like there are still some other solver parameters needing attention.

[EdmundStephens]

This is what happens at the moment (timescale in days). Obviously not quite working yet ... any comments welcome, or would it be preferable for me to post this as a separate and different issue ?

[totto82]

I trried to run it with

EclDeckFileName="H1f" # default: ""
OutputDir="testOutputTUN" # default: ""
ParsingStrictness="low" # default: "normal"
UseGmres="true" # default: "0"
LinearSolver="cpr" # default: "ilu0"
ToleranceCnvRelaxed="0.01" # default: "1"
ToleranceMb="1e-8" # default: "1e-06"
EclEnableDriftCompensation="false" # default: "1"
MinTimeStepBeforeShuttingProblematicWellsInDays="1e-8" # default: "0.01"
EnableWellOperabilityCheck="false" # default: "1"

It struggles and takes forever to run, but it seems to give some results. These results are without WATDENT. I started a run with WATDENT but that havn't finished yet.

Note especially  EclEnableDriftCompensation=false
ToleranceCnvRelaxed=0.01. 

This will make sure that the strict tolerance of 0.01 is used for all cells.
and

MinTimeStepBeforeShuttingProblematicWellsInDays="1e-8" # default: "0.01"
EnableWellOperabilityCheck="false" # default: "1"

Which hopefully will help to avoid to early shutting of wells.