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