[petsc-users] odd SNES behavior

[Dmitry Karpeev]

On Mar 6, 2013 10:29 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
>
>
> On Mar 6, 2013, at 10:19 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
> > I suggested using 'exact' in place of 'true'. I guess it might have
gotten folded into "quoted text" or otherwise squeezed out.
>
>   Ok, thanks.
>
>   It also is problematic since the mat is not necessarily "exact", it
just might be "better" than the pmat.

This is a small thing, but it would be good to come up with consistent
terminology for naming mat and pmat in general. Saying 'preconditioner',
when meaning 'pmat', is rather common, but incorrect. Using 'preconditioner
matrix' or something similar to distinguish pmat from the PC is too
verbose. That naming convention would also take care of the specific use
being discussed here. I like Mark's 'op' and 'preop'.
Dmitry.
>
>    Barry
>
> >
> > Dmitry.
> >
> > On Mar 6, 2013 10:16 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> >
> >   Dmitry
> >
> >   Did you have something to say? Nothing appeared new appeared in the
email you sent.
> >
> >   Barry
> >
> > On Mar 6, 2013, at 10:09 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> >
> > >
> > > On Mar 6, 2013 10:05 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > > >
> > > >
> > > > On Mar 6, 2013, at 9:36 PM, "Mark F. Adams" <mark.adams at columbia.edu>
wrote:
> > > >
> > > > >>
> > > > >> Presumbly when you call PCReset() it zeros out all the pointers.
If you do not set the operators on the finest level again then it will use
the "outer" operator on the smoothest level. Is this the problem?
> > > > >
> > > > > This is not a problem but it should be a choice, right?
> > > >
> > > > > This app has an expensive nonlinear 'formFunction' but many apps
will have fast matrix free apply-operator methods, in which case the
current behavior with gamg is desired.  And having this choice being made
by whether a PC is well integrated with PETSc (e.g., not hypre) is pretty
awful semantics.
> > > > >
> > > > > Is there an option that will make this happen or should I add
one?  If so where should I add it? It should be in PC_MG I would think.
> > > > >
> > > > > -pc_mg_levels_fine_use_op <false>
> > > > > -pc_mg_levels_fine_use_preop <true>
> > > >
> > > > Mark,
> > > >
> > > >    This same issue comes up in several preconditioners. We use the
term True to indicate this (yes maybe not the best term)
> > > >
> > > > Barrys-MacBook-Pro:petsc-dev barrysmith$ grep True include/petscpc.h
> > > > PETSC_EXTERN PetscErrorCode PCBJacobiSetUseTrueLocal(PC);
-pc_bjacobi_truelocal
> > > > PETSC_EXTERN PetscErrorCode PCKSPSetUseTrue(PC);
-pc_ksp_true
> > > > PETSC_EXTERN PetscErrorCode PCCompositeSetUseTrue(PC);
-pc_composite_true
> > > >
> > > >  There are possibly other PCs that could have this functionality
but do not because we haven't realized it. It makes sense in any PC that
internally has to apply the "full" (or part of the full) operator somewhere
inside the application of the PC.
> > > >
> > > >   So you could add PCMGSetUseTrue(PC) and -pc_mg_true  that would
trigger setting the true (outer) operator inside the PCSetUp_MG() even if
it was already set. You would still change/fix the current GAMG to always
set the operators on the finest level using the pmat (which could be
overwritten by the user with the PCMGSetUseTrue() or -pc_mg_true option.
> > > >
> > > >   It may also make sense to move the use true flag and
functionality up to the PC level (out of the subclasses) thus unifying its
usage (or not)? PCSetUseTrue(), -pc_true.**
> > > >
> > > >   Suggestions to alternatives to "True" (that are concise yet
descriptive) are also solicited.
> > > 'exact'?
> > > >
> > > >
> > > >    Barry
> > > >
> > > > ** note that in some complicated PCs there may be several different
applications of the full (or part of the full) operator inside the
application of the PC. Conceivably one may want to use True on some and not
on others but we've never dealt with that.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130306/215c3e43/attachment.html>