[petsc-users] Snes ex22.c

[Barry Smith]

    Ryan,

      This is because the "explicit Jacobian" computed in ex22.c is  
not correct. Run with -snes_type test -dmmg_nlevels 1

      This is because the code cannot determine the nonzero structure  
of the Jacobian and (also) hence a coloring of the Jacobian.

      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

      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.

      The DMComposite stuff in PETSc is pretty rough.

     I will add a note to ex22.c explaining why it doesn't work with  
matrix based.

     Barry


On Mar 29, 2010, at 11:17 AM, Ryan Yan wrote:

> Dear All,
> Could someone help to answer a question about snes/ex22.c?
> I runed the program twice with two different option sets.
>
> In the first run,  I used:
> mpirun -np 1 ./ex22 -da_grid_x 10 -snes_monitor
>
> this will invoke all the matrix_free_options at line 96.   It is  
> shown that on all grid levels we have a aggressive convergence.
> http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/snes/examples/tutorials/ex22.c.html
>           0 SNES Function norm 6.285393610547e-01
>           1 SNES Function norm 3.743759728398e-06
>           2 SNES Function norm 2.855651342153e-11
>         0 SNES Function norm 4.708310005567e-01
>         1 SNES Function norm 2.696769540300e-06
>         2 SNES Function norm 9.009613143190e-12
>       0 SNES Function norm 3.456250981375e-01
>       1 SNES Function norm 3.224179904192e-07
>       2 SNES Function norm 8.831908707996e-13
>     0 SNES Function norm 2.565116065949e-01
>     1 SNES Function norm 2.781184363175e-08
>     2 SNES Function norm 1.880008919009e-14
>   0 SNES Function norm 1.957654311750e-01
>   1 SNES Function norm 4.039546692288e-07
>   2 SNES Function norm 3.668272652964e-13
>
>
> In the second run, I use the matrix based method, with the following  
> options
> mpirun -np 1 ./ex22 -da_grid_x 10 -use_matrix_based -ksp_type fgmres  
> -snes_monitor
> (The reason why I use fgmres is because I want to compare the result  
> with the first run.)
> No significant convergence can be obtained at this run.
>            0 SNES Function norm 6.285393610547e-01
>            1 SNES Function norm 1.646083626629e-01
>          0 SNES Function norm 6.321514185793e-01
>        0 SNES Function norm 1.046493792681e+00
>      0 SNES Function norm 1.906667654680e+00
>    0 SNES Function norm 3.721097900524e+00
>
>
> 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.
>
> An deeper check using -ksp_monitor will show that for the second  
> run, within each newton inner loop the ksp residual stagnates.
>
> I guess my question is: Is this behavior normal and how to  
> understand this?
> 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?
>
> Thank you very much,
>
> Yan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20100329/37cbc50a/attachment.htm>