opm-simulators Challenges and errors modelling for geothermal study

Challenges and errors modelling for geothermal study

Open EdmundStephens opened this issue 1 year ago • 0 comments

[v2023.10] I am helping a group understand their geothermal development involving a porous aquifer with heterogeneous fracturing and significant 4% mol frac dissolved CO2. The proposed scheme is a cold water reinjection (it is a regulatory requirement to reinject into the same aquifer) where the produced CO2 must also be reinjected. The question to resolve is what happens to the CO2, since reinjection is focused into the small fracture pore volume solubility being temperature dependent. CO2 saturation is at around 6.5% mol frac, and if this is exceeded dense phase CO2 will separate and short circuit the fluid circulation through the fracture pore volume, having lower density and much higher mobility.

This is a long journey but the effort has turned up a few bugs in Flow which are worth noting and fixing. Important to acknowledge that as far as I am aware the industry standard simulators (Eclipse, tNav) are not be capable of modelling thermal + fractures + CO2 EOS and solubility, whereas I believe Flow should be able to model this. The dual porosity can be represented by a ‘synthetic dual’ model (see below) and I believe the black oil type representation of CO2 in Flow will be more successful than black box compositional approaches. For reference various bugs with the thermal + fractures (e.g. conduction from base matrix to top fractures); Eclipse does not implement a separate thermal transmissibility in NNCs; tNavigator has bugs solving for CO2 solubility in their CO2STORE thermal-compositional module.

This is the manifesto for modelling this problem:

‘Synthetic dual’ method represents the dual porosity system in a single porosity grid: o Duplicate the grid layers with matrix porosity in the upper grid and fracture porosity in the lower grid o The fracture grid corner points are vertically offset, in this case by 600 m o The grid DEPTH array is corrected in the EDIT section such that fluid potentials are correct
Fracture-matrix coupling is specified as non-neighbour connections: o Convective transmissibility TRANSNNC = PERM * SIGMAV * CELLVOLUME… NNC argument 7 o Thermal transmissibility THCONNCC = THCONMF * SIGMAV * CELLVOLUME … NNC argument 15 (this is the
Include CO2 using solubility per v2023-04 functionality (DISGASW etc.) and injection streams (WINJGAS etc.).

So far I have approached steps 1 and 2, and I think Flow should be capable of this type of synthetic dual model within existing functionality. Below example plots of a synthetic dual thermal flood in tNavigator, which exactly duplicates the energy flows in the dual poro/perm model and also from the explicit fracture model, including cold water and passive tracer breakthroughs. Step 3 is our desired destination, but that relies on the above two steps.

Test models attached are as follows with some pictures below to illustrate:

Grav1ex-E: explicit single phase - single porosity representation of the trial system (input and summary) with 300 x 75 x 25 grid, area 1 km x 250 m, thickness 500 m, poro 0.04 total, 0.001 in fractures every 50 m, perm 200 md total with 1.0 md in the matrix. The model has a periodic log scaled grid outward from the fracture cells and is equivalent to fracture porosity 0.001 and a (Kazemi) shape factor 0.0032/m2.
Grav1dp-T: equivalent dual poro/perm model in a 50 x 5 x 25 grid
Grav1syn-T: synthetic dual poro/perm model in a 50 x 5 x 25 grid
Grav1syn-F1: model in Flow with no NNCs (i.e. illustrating the DEPTH issue)
Grav1syn-F2: model in Flow importing NNCs … model crashes on first timestep
Grav1syn-F3: model in Flow importing NNCs with default NNCs … model crashes on first timestep

Issues for Flow

In Grav1syn-F1 the correction to DEPTH in the EDIT keyword is not actually resulting in a changed DEPTH array, and the same goes for OPERATE or defining a BOX and importing DEPTH array data directly. This is already report as issue 3919 (“Bug with operations on DEPTH array in EDIT section”).
In Grav1syn-F2, which should replicate In Grav1syn-T, Flow crashes on import of the NNC file with the following error:

Starting time step 0, stepsize 0.00099537 days, at day 0/0.00099537, date = 01-Jan-2020
Restart file written for report step   0/240, date = 01-Jan-2020 00:00:00
flow: /usr/include/opm/models/discretization/common/fvbaselocalresidual.hh:318: void Opm::FvBaseLocalResidual<TypeTag>::evalFluxes(Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector&, const ElementContext&, unsigned int) const [with TypeTag = Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy; Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector = Dune::BlockVector<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, Opm::aligned_allocator<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, 8> >; typename Opm::Properties::Detail::GetPropImpl<TypeTag, Opm::Properties::Evaluation>::type::type = Opm::DenseAd::Evaluation<double, 2, 0>; Opm::FvBaseLocalResidual<TypeTag>::ElementContext = Opm::FvBaseElementContext<Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy>]: Assertion `isfinite(flux[eqIdx])' failed.
flow: /usr/include/opm/models/discretization/common/fvbaselocalresidual.hh:318: void Opm::FvBaseLocalResidual<TypeTag>::evalFluxes(Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector&, const ElementContext&, unsigned int) const [with TypeTag = Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy; Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector = Dune::BlockVector<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, Opm::aligned_allocator<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, 8> >; typename Opm::Properties::Detail::GetPropImpl<TypeTag, Opm::Properties::Evaluation>::type::type = Opm::DenseAd::Evaluation<double, 2, 0>; Opm::FvBaseLocalResidual<TypeTag>::ElementContext = Opm::FvBaseElementContext<Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy>]: Assertion `isfinite(flux[eqIdx])' failed.
[DESKTOP-8VC26F1:00035] *** Process received signal ***
[DESKTOP-8VC26F1:00035] Signal: Aborted (6)
[DESKTOP-8VC26F1:00035] Signal code:  (-6)
/bin/bash: line 1:    35 Aborted                 flow --parameter-file=Grav1syn-F2.param Grav1syn-F2

In the .DBG file is noted that argument 15 of NNC is not supported: this is correct as of Flow 2023.04 but in Eclispe and tNav thermal mode becomes the Thermal conduction transmissibility value of the non-neighbor connection.

  NNC: invalid value '45782.400000' in record 1 for item 15
  In file: /mnt/c/Working/Slatina Ph2, 2024/Reservoir/Modelling/Flow_test/Grav1_NNC.inc, line 4
  NNC(DISPNNC): not supported

In Grav1syn-F3 is a test of NNCs without argument 15 but unfortunately still crashes with the following error:

Starting time step 0, stepsize 0.00099537 days, at day 0/0.00099537, date = 01-Jan-2020
Restart file written for report step   0/240, date = 01-Jan-2020 00:00:00
flow: /usr/include/opm/models/discretization/common/fvbaselocalresidual.hh:318: void Opm::FvBaseLocalResidual<TypeTag>::evalFluxes(Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector&, const ElementContext&, unsigned int) const [with TypeTag = Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy; Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector = Dune::BlockVector<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, Opm::aligned_allocator<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, 8> >; typename Opm::Properties::Detail::GetPropImpl<TypeTag, Opm::Properties::Evaluation>::type::type = Opm::DenseAd::Evaluation<double, 2, 0>; Opm::FvBaseLocalResidual<TypeTag>::ElementContext = Opm::FvBaseElementContext<Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy>]: Assertion `isfinite(flux[eqIdx])' failed.
[DESKTOP-8VC26F1:00010] *** Process received signal ***
flow: /usr/include/opm/models/discretization/common/fvbaselocalresidual.hh:318: void Opm::FvBaseLocalResidual<TypeTag>::evalFluxes(Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector&, const ElementContext&, unsigned int) const [with TypeTag = Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy; Opm::FvBaseLocalResidual<TypeTag>::LocalEvalBlockVector = Dune::BlockVector<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, Opm::aligned_allocator<Dune::FieldVector<Opm::DenseAd::Evaluation<double, 2, 0>, 2>, 8> >; typename Opm::Properties::Detail::GetPropImpl<TypeTag, Opm::Properties::Evaluation>::type::type = Opm::DenseAd::Evaluation<double, 2, 0>; Opm::FvBaseLocalResidual<TypeTag>::ElementContext = Opm::FvBaseElementContext<Opm::Properties::TTag::EclFlowProblemWaterOnlyEnergy>]: Assertion `isfinite(flux[eqIdx])' failed.
[DESKTOP-8VC26F1:00010] Signal: Aborted (6)
[DESKTOP-8VC26F1:00010] Signal code:  (-6)
/bin/bash: line 1:    10 Aborted                 flow --parameter-file=Grav1syn-F3.param Grav1syn-F3

(Worth noting that the absence of NNC thermal conductivity is not a showstopper for this study; a workaround is to note that only the product PERM x SIGMAV is important, so the model can have scaled perms such that the conductivity transfer is correct, and compensate for the matrix transmissibility via MULTX and MULTY ... this is a bit ugly but does work, for example in Eclipse where NNC argument 15 is not implemented in the black oil thermal model).

Please can you have a look into these models in case something is missing and/or differently implemented in Flow that is causing these problems. I do not know if these are triggered in particular by operating in single phase and/or thermal mode. The idea is when the synthetic dual base model is operational, I want to push forward and complete the model using Flow’s CO2STORE functionality.

Models: Grav1ex-E.zip Grav1dp-T.zip Grav1syn-T.zip Grav1syn-F1.zip Grav1syn-F2.zip Grav1syn-F3.zip

Explicit single porosity model of the fractured system