Two-point stress approximation (TPSA) geomechanics

[svenn-t]

This PR introduces the implementation of TPSA geomechanics solver with coupling to Flow. Most important features are:

• TPSA-Flow coupling done at the nonlinear solver step level:
  • Lagged coupling -> TPSA lags behind one time step
  • Fixed-stress -> Iterate until Flow and TPSA converge
• Generic TPSA solver using Newton with associated linearizer
• Linear elasticity equations implemented
• Specialized version of ISTL linear solver for TPSA
• Output to restart files and VTK

There are blackoil, gas-water dissolution (mostly for CO2-/H2STORE) and one-phase simulators implemented, but in principle any other simulator can be generated as well.

Reference to implementation paper can be found here.

Putting this PR in draft mode since it is rather large, but any feedback/comments/discussion on the implementation is welcome at this point!

Companion PR: OPM/opm-common#4846

[bska]

I'll just make one general comment here and then I'll be quiet. Adding 6,600 lines of new code in a single PR, especially since there's hardly any unit tests, is usually not the best way to go about making the PR easy to review.

Is there no way to split this up into smaller parts, ideally with documentation and unit test coverage for each part?

[akva2]

Since it's entirely a one way dependency, how about we extract the block size 7 changes and do those first?

[svenn-t]

Since it's entirely a one way dependency, how about we extract the block size 7 changes and do those first?

I have made a new PR #6660 with only the block size increase. Thanks for the suggestion @akva2! The number of GPU-related files that needed to be modified was more than I thought initially! I will rebase this PR once the block size PR is merged.

I'll just make one general comment here and then I'll be quiet. Adding 6,600 lines of new code in a single PR, especially since there's hardly any unit tests, is usually not the best way to go about making the PR easy to review.

Is there no way to split this up into smaller parts, ideally with documentation and unit test coverage for each part?

Thanks for the comment @bska. I have added some additional unit tests, including the PR in opm-tests OPM/opm-tests#1440. I hope this covers and shows the workings of the TPSA code better. I can also add that TPSA, structurally speaking, is (almost) a straightforward copy of TPFA in Flow. I hope this will make it easier to review.

[bska]

I have added some additional unit tests, including the PR in opm-tests

Thanks for adding tests, that certainly aids in the review.

Tangentially, my own personal goal when I'm adding new code is to cover the public interface of each new class and public function with a comprehensive set of unit tests. I also try to make adding each class/public function into a separate PR and then having an integration PR at the end that ties everything together and activates the new logic. I don't always achieve this goal but it feels good when I do.

[svenn-t]

An issue I have found is that the flow executable does not show the TPSA-related parameters (i.e., command-line options starting with "--tpsa"). The TPSA-specific simulators, f.ex. flow_blackoil_tpsa, show the parameters just fine. I suspect it's related to the FlowEarlyBird type tag in Main.hpp not knowing about TPSA-related definitions, and thereby the TPSA parameters will not be registered for flow (?).

If anyone has any ideas how to get the TPSA parameters in flow or some hints/suggestions what I should try, it will be much appreciated!

[akva2]

Sadly this is a limitation of the system. The same applies to other model specific options, such as solvent.
We never put in the effort to make this behave properly, nor made a decision on what is proper behavior.

To make it work, you have to register the parameters manually, since, as you allude to, they are not registered through the FlowEarlyBird typetag since it has the standard blackoil model. One way of achieving this conceptually is by adding a call to the registration function in

SimulatorFullyImplicitBlackoil::registerParameters()

[hnil]

I had a brief look. This seems very good new contributions. It is an alternative to part of opm-flowgeomechanics, which do vem discretization + some fracturing. You have done a very good job at getting things into the system with models +++, which is partly avoided in opm-flowgeomechanics. Also maybe the work in opm-flowgeomechanics should be changed a bit to be more like "opm" interface as the tpsa uses.

Some comments:

• maybe even more could have been done with separate classes which inherits from main classes
• it would be usefull to sync part of the classes with opm-flowgeomechanics so solvers can be interchanged. I see you had to adapt to some output which was already merged into master, probably the same is the case for input in particular boundary conditions.
• Also I will recommand to look at using hypre based solver. It seems to be much more stable in particular non default partition is required which normally is better for mechanics.

[svenn-t]

Sadly this is a limitation of the system. The same applies to other model specific options, such as solvent. We never put in the effort to make this behave properly, nor made a decision on what is proper behavior.

To make it work, you have to register the parameters manually, since, as you allude to, they are not registered through the FlowEarlyBird typetag since it has the standard blackoil model. One way of achieving this conceptually is by adding a call to the registration function in

SimulatorFullyImplicitBlackoil::registerParameters()

Thanks for the hint! I have included linear solver and newton parameters for TPSA directly in SimulatorFullyImplicitBlackoil::registerParameters() in the latest update. It might not be the most elegant solution since these are very specific parameters for TPSA included in the general simulator class, but it seems to work at least!

[svenn-t]

I had a brief look. This seems very good new contributions. It is an alternative to part of opm-flowgeomechanics, which do vem discretization + some fracturing. You have done a very good job at getting things into the system with models +++, which is partly avoided in opm-flowgeomechanics. Also maybe the work in opm-flowgeomechanics should be changed a bit to be more like "opm" interface as the tpsa uses.

Thanks for the feedback, @hnil. I appreciate you taking the time to have a look at this.

Some comments:

maybe even more could have been done with separate classes which inherits from main classes

Yes, there may be some classes which I have name somethingTPSA (like FlowProblemTPSA, BlackoilModelTPSA, ISTLSolverTPSA) which could be generalized to fit any geomechanics model.

it would be usefull to sync part of the classes with opm-flowgeomechanics so solvers can be interchanged. I see you had to adapt to some output which was already merged into master, probably the same is the case for input in particular boundary conditions.

We are still figuring out some of the outputs (particularly stress and strain) and boundary conditions (particularly Robin conditions). It would be worth syncing up with opm-flowgeomechanics, in general, to avoid duplicating code!

Also I will recommand to look at using hypre based solver. It seems to be much more stable in particular non default partition is required which normally is better for mechanics.

Thanks, I will look into hypre-based solvers! ISTL solvers have worked great, at least on the examples we have run so far, which I think is due to the nature of TPSA being closely related to TPFA.