MGR: Bad linear solver convergence for poromechanics case with fractures

[paveltomin]

Example 1 (conforming):
PoroElastic_conformingFracture_2d_faultSlip
switch to MGR:

      <LinearSolverParameters
        solverType="fgmres"
        preconditionerType="mgr"
        logLevel="1"
      />

run and observe:

Time: 0.00e+00 s, dt: 100 s, Cycle: 0

  Number of element for each fracture state: stick:           80 | slip:             0 | open:             0
    Attempt:  0, ConfigurationIter:  0, NewtonIter:  0
        ( Rflow ) = ( 1.34e+02 )        ( Rsolid ) = ( 4.68e+08 )        ( Rdisplacement, Rtraction, Rtotal ) = (    1.000000e+00,    1.000000e+00,    1.000000e+00 )        ( R ) = ( 4.68e+08 )
        MGR preconditioner: numComponentsPerField = [3, 3, 1]
        Linear Solver | Success | Iterations: 80 | Final Rel Res: 8.91421e-07 | Make Restrictor Time: 0 | Compute Auu Time: 0 | SC Filter Time: 0 | Setup Time: 0.238624 s | Solve Time: 2.12301 s
        Last LinSolve(iter,res) = (  80, 8.91e-07 )
        flowSolver: Max pressure change: 14074.399 Pa (before scaling)
        poroSolver: Global solution scaling factor = 1
        flowSolver: Number of negative pressure values: 650, minimum value: -13586.745 Pa
    Attempt:  0, ConfigurationIter:  0, NewtonIter:  1
        ( Rflow ) = ( 1.48e-06 )        ( Rsolid ) = ( 4.17e+02 )        ( Rdisplacement, Rtraction, Rtotal ) = (    8.914212e-07,    4.069220e-07,    8.914212e-07 )        ( R ) = ( 4.17e+02 )
        MGR preconditioner: numComponentsPerField = [3, 3, 1]
        Linear Solver | NotConverged | Iterations: 200 | Final Rel Res: 0.000558784 | Make Restrictor Time: 0 | Compute Auu Time: 0 | SC Filter Time: 0 | Setup Time: 0.234295 s | Solve Time: 5.7737 s
        Last LinSolve(iter,res) = ( 200, 5.59e-04 )
        flowSolver: Max pressure change: 158.478 Pa (before scaling)
        poroSolver: Global solution scaling factor = 1
        flowSolver: Number of negative pressure values: 650, minimum value: -13581.952 Pa
    Attempt:  0, ConfigurationIter:  0, NewtonIter:  2
        ( Rflow ) = ( 5.72e-10 )        ( Rsolid ) = ( 2.33e-01 )        ( Rdisplacement, Rtraction, Rtotal ) = (    4.981216e-10,    1.023570e-10,    4.981216e-10 )        ( R ) = ( 2.33e-01 )
        MGR preconditioner: numComponentsPerField = [3, 3, 1]
        Linear Solver | NotConverged | Iterations: 200 | Final Rel Res: 0.0133972 | Make Restrictor Time: 0 | Compute Auu Time: 0 | SC Filter Time: 0 | Setup Time: 0.239527 s | Solve Time: 5.71636 s
        Last LinSolve(iter,res) = ( 200, 1.34e-02 )
        flowSolver: Max pressure change: 0.047 Pa (before scaling)
        poroSolver: Global solution scaling factor = 1
        flowSolver: Number of negative pressure values: 650, minimum value: -13581.951 Pa
    Attempt:  0, ConfigurationIter:  0, NewtonIter:  3
        ( Rflow ) = ( 1.01e-11 )        ( Rsolid ) = ( 3.13e-03 )        ( Rdisplacement, Rtraction, Rtotal ) = (    6.673488e-12,    1.574757e-12,    6.673488e-12 )        ( R ) = ( 3.13e-03 )
        MGR preconditioner: numComponentsPerField = [3, 3, 1]
        Linear Solver | NotConverged | Iterations: 200 | Final Rel Res: 0.00803326 | Make Restrictor Time: 0 | Compute Auu Time: 0 | SC Filter Time: 0 | Setup Time: 0.236079 s | Solve Time: 5.72704 s
        Last LinSolve(iter,res) = ( 200, 8.03e-03 )

Examples 2 (EDFM): https://github.com/GEOS-DEV/GEOS/blob/develop/inputFiles/poromechanicsFractures/SlipPermeability_embeddedFrac.xml
and SlipPermeability_pEDFM_smoke.xml
similar convergence issues observed.

[paveltomin]

The issue can be related to the equation order change after #2967, see below

new order

old order

hopefully an easy fix

[victorapm]

The issue can be related to the equation order

Yes, we need to update the MGR strategies accordingly. I can take a look

[paveltomin]

The issue can be related to the equation order

Yes, we need to update the MGR strategies accordingly. I can take a look

Thank you, @victorapm!

[CusiniM]

The issue can be related to the equation order

Yes, we need to update the MGR strategies accordingly. I can take a look

I think we need to change the way these mgr strategies are defined so that we avoid this kind of issue. We fix the ordering statically in the mgr strategies but the actual ordering of the fields is defined at execution. It can get tricky now that we start combining a lot of solvers.

[CusiniM]

The issue can be related to the equation order

Yes, we need to update the MGR strategies accordingly. I can take a look

I think we need to change the way these mgr strategies are defined so that we avoid this kind of issue. We fix the ordering statically in the mgr strategies but the actual ordering of the fields is defined at execution. It can get tricky now that we start combining a lot of solvers.

To be more precise, the ordering depends on the order in which the functions to add fields to the dofManager are called so technically we can know it before execution but I still think that it is tricky to keep track of this and, if it changes like in this case, we have no test to catch the issue.