[petsc-users] Snes ex22.c

[Ryan Yan]

Dear Barry,
Thank you very much for the clarification and pointers to other utilities
for problems with coupling.

And exactly,  -dmcomposite_dense_jacobian make the code converged
aggressively.

Cheers,

Yan

On Mon, Mar 29, 2010 at 6:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>    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/008f6b1d/attachment.htm>