<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#330033" bgcolor="#FFFFFF">

    Attached the PFLOTRAN default run (KSPBCGS + PCBJacobi + PCILU) for

    the same input file.<br>

    <br>

    NP 1<br>

    <br>

    FLOW TS BE steps =     43 newton =       43 linear =       3950 cuts

    =      0<br>

    FLOW TS BE Wasted Linear Iterations = 0<br>

    FLOW TS BE SNES time = 27.6 seconds<br>

    <br>

    NP 2<br>

    <br>

    FLOW TS BE steps =     43 newton =       43 linear =       4585 cuts

    =      0<br>

    FLOW TS BE Wasted Linear Iterations = 0<br>

    FLOW TS BE SNES time = 21.5 seconds<br>

    <br>

    <br>

    <br>

    Based on your idea to fix all knobs but one I did a direct solve

    test on all the PC and KSP's within the SNES I'm using. Simply put

    my SNES looks like this:<br>

    <br>

    <br>

    SNES<br>

      - LS:   basic<br>

      - KSP:  FGMRES<br>

      - PC:   Composite, multiplicative<br>

    <br>

        - PC:   Galerkin<br>

          - KSP:  GMRES<br>

          - PC:   Hypre BoomerAMG<br>

          - SetRestriction:       user-defined<br>

          - SetComputeSubMatrix:  user-defined<br>

          - SetInterpolation:     User-defined<br>

    <br>

        - PC:   BJacobi<br>

          - KSP:  Preonly<br>

          - PC:   LU<br>

    <br>

    I want to test direct solves on both PCComposite branches sub 0 and

    sub 1 and without PCGalerkin (2 tests), and then include PCGalerkin

    (2 tests), with a final test emulating the Two Stage PC to also

    stress the user-defined functions in PCGalerkin by doing a double

    direct solve (1 test, pressure solve first, than whole system with

    the hyperbolic component included). <br>

    <br>

    Long story short: Most tests require 43 Newton and Linear Steps. The

    last test shows problematic behaviour, and consumes all my memory

    including swap (16 GB + 16 GB).  I can recall an issue with

    automatically generated Fortran callback (?) for ComputeSubMatrix()

    issue Matt was mentioning a long while ago..<br>

    <br>

    <br>

    <b> Test 2 (Check PCComposite Sub 0)</b><br>

    <br>

    mpirun \<br>

      -n ${NP} pflotran \<br>

      -pflotranin ${INPUTFILE}.pflinput \<br>

      -flow_ksp_type preonly \<br>

      -flow_sub_0_pc_type bjacobi \<br>

      -flow_sub_0_sub_pc_type lu \<br>

      -flow_sub_0_sub_pc_factor_

    <div bgcolor="#FFFFFF"><wbr>nonzeros_along_diagonal \<br>

        -flow_sub_1_pc_type none \<br>

        -snes_monitor \<br>

        -log_view \<br>

        2>&1 > ${OUTPUTFILE}_test_2.log | tee -a

      ${OUTPUTFILE}_test_2.log <br>

      <br>

      NP 1<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 215.2 seconds<br>

      <br>

      NP 2<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 53.7 seconds<br>

      <br>

      OK<br>

      <br>

      <br>

      <br>

      <b> Test 3 (Check PCComposite Sub 1)</b><br>

      <br>

      mpirun \<br>

        -n ${NP} pflotran \<br>

        -pflotranin ${INPUTFILE}.pflinput \<br>

        -flow_ksp_type preonly \<br>

        -flow_sub_0_pc_type none \<br>

        -flow_sub_1_pc_type bjacobi \<br>

        -flow_sub_1_sub_pc_type lu \<br>

        -flow_sub_1_sub_pc_factor_<wbr>nonzeros_along_diagonal \<br>

        -snes_monitor \<br>

        -log_view \<br>

        2>&1 > ${OUTPUTFILE}_test_3.log | tee -a

      ${OUTPUTFILE}_test_3.log <br>

      <br>

      NP 1<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 195.3 seconds<br>

      <br>

      NP 2<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 53.1 seconds<br>

      <br>

      OK<br>

      <br>

      <br>

      <br>

      <br>

      <b> Test 4 (Check PCComposite Sub 1 with empty PCGalerkin on Sub

        0)</b><br>

      <br>

      mpirun \<br>

        -n ${NP} pflotran \<br>

        -pflotranin ${INPUTFILE}.pflinput \<br>

        -flow_ksp_type preonly \<br>

        -flow_sub_0_galerkin_ksp_type preonly \<br>

        -flow_sub_0_galerkin_pc_type none \<br>

        -flow_sub_1_pc_type bjacobi \<br>

        -flow_sub_1_sub_pc_type lu \<br>

        -flow_sub_1_sub_pc_factor_<wbr>nonzeros_along_diagonal \<br>

        -snes_monitor \<br>

        -log_view \<br>

        2>&1 > ${OUTPUTFILE}_test_4.log | tee -a

      ${OUTPUTFILE}_test_4.log <br>

      <br>

      NP 1<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 201.0 seconds<br>

      <br>

      NP2<br>

      <br>

      FLOW TS BE steps =     43 newton =       43 linear =         43

      cuts =      0<br>

      FLOW TS BE Wasted Linear Iterations = 0<br>

      FLOW TS BE SNES time = 61.1 seconds<br>

      <br>

      OK<br>

      <br>

      <br>

      <br>

      <b> Test 5 (Check </b><b>PCComposite</b><b> Sub 0 with populated

        PCGalerkin on Sub 0)</b><br>

      <br>

      <br>

      mpirun \<br>

        -n ${NP} pflotran \<br>

        -pflotranin ${INPUTFILE}.pflinput \<br>

        -flow_ksp_type preonly \<br>

        -flow_sub_0_galerkin_ksp_type preonly \<br>

        -flow_sub_0_galerkin_pc_type bjacobi \<br>

        -flow_sub_0_galerkin_sub_pc_<wbr>type lu \<br>

        -flow_sub_0_galerkin_sub_pc_<wbr>factor_nonzeros_along_diagonal

      \<br>

        -flow_sub_1_ksp_type preonly \<br>

        -flow_sub_1_pc_type none \<br>

        -snes_monitor \<br>

        -log_view \<br>

        2>&1 > ${OUTPUTFILE}_test_5.log | tee -a

      ${OUTPUTFILE}_test_5.log <br>

      <br>

      NP 1<br>

      <br>

      FLOW TS BE steps =    142 newton =      294 linear =        294

      cuts =     19<br>

      FLOW TS BE Wasted Linear Iterations = 152<br>

      FLOW TS BE SNES time = 291.5 seconds<br>

      <br>

      NP 2<br>

      <br>

      FLOW TS BE steps =    118 newton =      238 linear =        238

      cuts =     15<br>

      FLOW TS BE Wasted Linear Iterations = 120<br>

      FLOW TS BE SNES time = 113.4 seconds<br>

      <br>

      LU only solves sub problem Ap<br>

      <br>

      <br>

      <b> Test 6 (Check PCComposite-PCGalerkin interaction)</b><br>

      <br>

      <br>

      mpirun \<br>

        -n ${NP} pflotran \<br>

        -pflotranin ${INPUTFILE}.pflinput \<br>

        -flow_ksp_type preonly \<br>

        -flow_sub_0_galerkin_ksp_type preonly \<br>

        -flow_sub_0_galerkin_pc_type bjacobi \<br>

        -flow_sub_0_galerkin_sub_pc_<wbr>type lu \<br>

        -flow_sub_0_galerkin_sub_pc_<wbr>factor_nonzeros_along_diagonal

      \<br>

        -flow_sub_1_ksp_type preonly \<br>

        -flow_sub_1_pc_type bjacobi \<br>

        -flow_sub_1_sub_pc_type lu \<br>

        -flow_sub_1_sub_pc_type bjacobi \<br>

        -flow_sub_1_sub_pc_factor_<wbr>nonzeros_along_diagonal \<br>

        -snes_monitor \<br>

        -log_view \<br>

        2>&1 > ${OUTPUTFILE}_test_6.log | tee -a

      ${OUTPUTFILE}_test_6.log <br>

      <br>

      NP = 1<br>

      <br>

       Step   1236 Time=  5.58118E-01 Dt=  2.97885E-05 [d]

      snes_conv_reason:    4<br>

        newton =   1 [    3135] linear =     1 [      3135] cuts =  0

      [   4]<br>

        --> SNES Linear/Non-Linear Iterations =            1 

      /            1<br>

        --> SNES Residual:   7.849082E-03  9.811352E-07  7.480307E-03<br>

        --> max chng: dpl=   3.3471E+03 dpo=   3.3471E+03  dso=  

      1.5938E-05 dt=   0.0000E+00<br>

      <br>

      Simulation takes forever and is ongoing as of writing.<br>

      <br>

      <br>

      NP = 2<br>

      <br>

       Step    950 Time=  4.45196E-01 Dt=  1.14579E-04 [d]

      snes_conv_reason:    4<br>

        newton =   3 [    3217] linear =     3 [      3217] cuts =  0

      [   0]<br>

        --> SNES Linear/Non-Linear Iterations =            3 

      /            3<br>

        --> SNES Residual:   2.777416E-02  3.471770E-06  1.976402E-02<br>

        --> max chng: dpl=   9.3491E+02 dpo=   9.3491E+02  dso=  

      5.8911E-05 dt=   0.0000E+00<br>

       <br>

      <br>

      == TOIL_IMS FLOW ==============================<wbr>==============================<wbr>====<br>

        0 SNES Function norm 2.830927483272e-02 <br>

        0 2r: 2.83E-02 2x: 0.00E+00 2u: 0.00E+00 ir: 1.98E-02 iu:

      0.00E+00 rsn:   0<br>

      <br>

      ==============================<wbr>==============================<wbr>=======================<br>

      =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES<br>

      =   PID 586 RUNNING AT mother<br>

      =   EXIT CODE: 9<br>

      =   CLEANING UP REMAINING PROCESSES<br>

      =   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES<br>

      ==============================<wbr>==============================<wbr>=======================<br>

      YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Killed (signal

      9)<br>

      This typically refers to a problem with your application.<br>

      Please see the FAQ page for debugging suggestions<br>

      <br>

      <br>

    </div>

    <br>

    <br>

    <div class="moz-cite-prefix">On 07/07/17 17:10, Barry Smith wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:A61BA5FF-D8A0-4FD1-8F44-663C59D8A9F9@mcs.anl.gov">

      <pre wrap="">

   I don't have a clue. It looks like the np 2 case just takes a different trajectory that runs into trouble that doesn't happen to np 1. Since the linear solves give very good convergence for both np 2 and np 1 I don't think the preconditioner is really the "problem".

   I absolutely do not like the fact that the code is not using a line search. If you look at even the sequential case SNES is sometimes stopping due to snorm even though the function norm has actually increased. Frankly I'm very suspicious of the "solution" of the time integration, it is too much "hit the engine a few times with the hammer until it does what it wants" engineering.

   What happens if you run the 1 and 2 process case with the "default" Pflotran linear solver? 

</pre>

      <blockquote type="cite">

        <pre wrap="">On Jul 7, 2017, at 6:05 AM, Robert Annewandter <a class="moz-txt-link-rfc2396E" href="mailto:robert.annewandter@opengosim.com"><robert.annewandter@opengosim.com></a> wrote:

Yes indeed, PFLOTRAN cuts timestep after 8 failed iterations of SNES. 

I've rerun with -snes_monitor (attached with canonical suffix), their -pc_type is always PCBJACOBI + PCLU (though we'd like to try SUPERLU in the future, however it works only with -mat_type aij..)

The sequential and parallel runs I did  with

    -ksp_type preonly -pc_type lu -pc_factor_nonzeros_along_diagonal -snes_monitor

and 

    -ksp_type preonly -pc_type bjacobi -sub_pc_type lu -sub_pc_factor_nonzeros_along_diagonal -snes_monitor

As expected, the sequential are bot identical and the parallel takes half the time compared to sequential.

On 07/07/17 01:20, Barry Smith wrote:

</pre>

        <blockquote type="cite">

          <pre wrap="">   Looks like PFLOTRAN has a maximum number of SNES iterations as 8 and cuts the timestep if that fails.

   Please run with -snes_monitor I don't understand the strange densely packed information that PFLOTRAN is printing.

   It looks like the linear solver is converging fine in parallel, normally then there is absolutely no reason that the Newton should behave different on 2 processors than 1 unless there is something wrong with the Jacobian. What is the -pc_type for the two cases LU or your fancy thing? 

   Please run sequential and parallel with -pc_type lu and also with -snes_monitor.  We need to fix all the knobs but one in order to understand what is going on.

   Barry

</pre>

          <blockquote type="cite">

            <pre wrap="">On Jul 6, 2017, at 5:11 PM, Robert Annewandter <a class="moz-txt-link-rfc2396E" href="mailto:robert.annewandter@opengosim.com"><robert.annewandter@opengosim.com></a>

 wrote:

Thanks Barry!

I've attached log files for np = 1 (SNES time: 218 s) and np = 2 (SNES time: 600 s). PFLOTRAN final output:

NP 1

FLOW TS BE steps =     43 newton =       43 linear =         43 cuts =      0

FLOW TS BE Wasted Linear Iterations = 0

FLOW TS BE SNES time = 218.9 seconds

NP 2

FLOW TS BE steps =     67 newton =      176 linear =        314 cuts =     13

FLOW TS BE Wasted Linear Iterations = 208

FLOW TS BE SNES time = 600.0 seconds

Robert

On 06/07/17 21:24, Barry Smith wrote:

</pre>

            <blockquote type="cite">

              <pre wrap="">   So on one process the outer linear solver takes a single iteration this is because the block Jacobi with LU and one block is a direct solver.

</pre>

              <blockquote type="cite">

                <pre wrap="">    11 KSP preconditioned resid norm 1.131868956745e+00 true resid norm 1.526261825526e-05 ||r(i)||/||b|| 1.485509868409e-05

[0] KSPConvergedDefault(): Linear solver has converged. Residual norm 2.148515820410e-14 is less than relative tolerance 1.000000000000e-07 times initial right hand side norm 1.581814306485e-02 at iteration 1

    1 KSP unpreconditioned resid norm 2.148515820410e-14 true resid norm 2.148698024622e-14 ||r(i)||/||b|| 1.358375642332e-12

</pre>

              </blockquote>

              <pre wrap="">   On two processes the outer linear solver takes a few iterations to solver, this is to be expected. 

   But what you sent doesn't give any indication about SNES not converging. Please turn off all inner linear solver monitoring and just run with -ksp_monitor_true_residual -snes_monitor -snes_lineseach_monitor -snes_converged_reason

   Barry

</pre>

              <blockquote type="cite">

                <pre wrap="">On Jul 6, 2017, at 2:03 PM, Robert Annewandter <a class="moz-txt-link-rfc2396E" href="mailto:robert.annewandter@opengosim.com"><robert.annewandter@opengosim.com></a>

 wrote:

Hi all,

I like to understand why the SNES of my CPR-AMG Two-Stage Preconditioner (with KSPFGMRES + multipl. PCComposite (PCGalerkin with KSPGMRES + BoomerAMG, PCBJacobi + PCLU init) on a 24,000 x 24,000 matrix) struggles to converge when using two cores instead of one. Because of the adaptive time stepping of the Newton, this leads to severe cuts in time step.

This is how I run it with two cores

mpirun \

  -n 2 pflotran \

  -pflotranin het.pflinput \

  -ksp_monitor_true_residual \

  -flow_snes_view \

  -flow_snes_converged_reason \

  -flow_sub_1_pc_type bjacobi \

  -flow_sub_1_sub_pc_type lu \

  -flow_sub_1_sub_pc_factor_pivot_in_blocks true\

  -flow_sub_1_sub_pc_factor_nonzeros_along_diagonal \

  -options_left \

  -log_summary \

  -info 

With one core I get (after grepping the crap away from -info):

 Step     32 Time=  1.80000E+01 

[...]

  0 2r: 1.58E-02 2x: 0.00E+00 2u: 0.00E+00 ir: 7.18E-03 iu: 0.00E+00 rsn:   0

[0] SNESComputeJacobian(): Rebuilding preconditioner

    Residual norms for flow_ solve.

    0 KSP unpreconditioned resid norm 1.581814306485e-02 true resid norm 1.581814306485e-02 ||r(i)||/||b|| 1.000000000000e+00