<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div> Ryan,<div><br></div><div> This is because the "explicit Jacobian" computed in ex22.c is not correct. Run with -snes_type test -dmmg_nlevels 1</div><div><br></div><div> This is because the code cannot determine the nonzero structure of the Jacobian and (also) hence a coloring of the Jacobian.</div><div><br></div><div> If you run with -dmcomposite_dense_jacobian it will converge the same way (it treats the Jacobian as dense hence does get the Jacobian computation correct). See the source code for DMComposite in src/dm/da/utils/pack.c</div><div><br></div><div> The routine DMCompositeSetCoupling() provides support for the user code to indicate any additional coupling between the different parts of the Jacobian. tutorials/multiphysics/mp.c shows an example of using this routine.</div><div><br></div><div> The DMComposite stuff in PETSc is pretty rough.</div><div><br></div><div> I will add a note to ex22.c explaining why it doesn't work with matrix based.</div><div><br></div><div> Barry</div><div><br></div><div><br><div><div>On Mar 29, 2010, at 11:17 AM, Ryan Yan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Dear All,<br>Could someone help to answer a question about snes/ex22.c?<br>I runed the program twice with two different option sets.<br><br>In the first run, I used:<br>mpirun -np 1 ./ex22 -da_grid_x 10 -snes_monitor <br> <br>this will invoke all the matrix_free_options at line 96. It is shown that on all grid levels we have a aggressive convergence.<br><a href="http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/snes/examples/tutorials/ex22.c.html">http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/snes/examples/tutorials/ex22.c.html</a><br> 0 SNES Function norm 6.285393610547e-01 <br> 1 SNES Function norm 3.743759728398e-06 <br> 2 SNES Function norm 2.855651342153e-11 <br> 0 SNES Function norm 4.708310005567e-01 <br> 1 SNES Function norm 2.696769540300e-06 <br> 2 SNES Function norm 9.009613143190e-12 <br> 0 SNES Function norm 3.456250981375e-01 <br> 1 SNES Function norm 3.224179904192e-07 <br> 2 SNES Function norm 8.831908707996e-13 <br> 0 SNES Function norm 2.565116065949e-01 <br> 1 SNES Function norm 2.781184363175e-08 <br> 2 SNES Function norm 1.880008919009e-14 <br> 0 SNES Function norm 1.957654311750e-01 <br> 1 SNES Function norm 4.039546692288e-07 <br> 2 SNES Function norm 3.668272652964e-13 <br> <br><br>In the second run, I use the matrix based method, with the following options<br>mpirun -np 1 ./ex22 -da_grid_x 10 -use_matrix_based -ksp_type fgmres -snes_monitor<br>(The reason why I use fgmres is because I want to compare the result with the first run.)<br> No significant convergence can be obtained at this run.<br> 0 SNES Function norm 6.285393610547e-01<br> 1 SNES Function norm 1.646083626629e-01<br> 0 SNES Function norm 6.321514185793e-01<br> 0 SNES Function norm 1.046493792681e+00<br> 0 SNES Function norm 1.906667654680e+00<br> 0 SNES Function norm 3.721097900524e+00<br><br><br>I have checked the ksp_view and snes_view for both cases. The only difference seems to me is that in the first run it is using matrix free method to achieve MatVec for the GMRES method(inside the Multigrid preconditioner ) for the error equation, and in the second run it is using a concrete matrix obtained from finite difference to achieve MatVec for the GMRES method(inside the Multigrid preconditioner ) for the error equation.<br> <br>An deeper check using -ksp_monitor will show that for the second run, within each newton inner loop the ksp residual stagnates. <br><br>I guess my question is: Is this behavior normal and how to understand this?<br>Or is there any other difference that I did not see in those two different test runs, except the way they use to achieve the MatVec?<br> <br>Thank you very much,<br><br>Yan<br></blockquote></div><br></div></body></html>