[petsc-users] odd SNES behavior

[Barry Smith]

On Mar 6, 2013, at 10:40 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> 
> 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.

   I have merged PCBJacobiSetUseTrueLocal(), -pc_bjacobi_true_local, PCKSPSetUseTrue(), -pc_ksp_true, PCCompositeSetUseTrue() -pc_composite_true to PCSetUserAmat(), -pc_use_amat  in petsc-dev.

   Note that other preconditioners, PCMG,  PCFieldSplit, PCASM, PCGASM should adopt the same flag but I will leave that to Mark and Jed.

   Yes, Amat is not great, but I don't like op and preop since we never use that terminology anywhere else in PETSc.

   Barry

> >
> >    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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> >