[petsc-dev] http://petsc.cs.iit.edu/petsc/petsc-dev/rev/a36eb42b26ee

[Dmitry Karpeev]

If you built a nested fieldsplit and wanted to look at the ksp monitor
output from all the levels of nesting, before this fix
the output would be extremely confusing.  This is because setting the tab
level on a PCFIELDSPLIT's inner KSPs doesn't
actually set the tab level on its PC.  If one of those PCs is itself a
PCFIELDSPLIT, its inner KSPs all of a sudden will not be indented enough
(with a bit of work I can generate sample output of this kind).  So, one
solution is to make sure that
setting a KSP's tab level forwards that to its PC as well.  There is
precedent for this in KSPSetOptionsPrefix(), which is what I followed.
 These calls are  KSP-specific because they also manipulate ithe KSP's
inner objects (the PC).
I guess we could make this call virtual by making
PetscObjectIncrementTabLevel() etc. dispatch through a function pointer.

Finally, note that it is the KSP is giving its tab level to the DM, not the
other way around.
This is probably inconsequential, unless you view the DM.

Dmitry.

On Thu, Jun 7, 2012 at 5:45 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Did we just adopt a new line formatting convention and nobody told me?
>
>           ierr =
> PetscObjectGetOptionsPrefix((PetscObject)(ilink->ksp),&prefix);
> CHKERRQ(ierr);
>           ierr = PetscObjectSetOptionsPrefix((PetscObject)(dms[i]),
> prefix);     CHKERRQ(ierr);
>           ierr = KSPSetDM(ilink->ksp, dms[i]);
>       CHKERRQ(ierr);
>           ierr = KSPSetDMActive(ilink->ksp, PETSC_FALSE);
>        CHKERRQ(ierr);
>           ierr =
> PetscObjectIncrementTabLevel((PetscObject)dms[i],(PetscObject)ilink->ksp,0);
> CHKERRQ(ierr);
>
>         }
>         else {
>
>         if(jac->reset)
>           SETERRQ(((PetscObject)pc)->comm,PETSC_ERR_SUP,"Cases not yet
> handled when PCReset() was used");
>
> Knowing Barry, he's going to fix this formatting the next time he runs
> across that file just to make it consistent (at the unfortunate expense of
> making "hg annotate" less useful until the tools get better about tracing
> backward through history).
>
> Is the tab level above even correct? Why would the KSP tab level be
> expected to match the DM tab level?
>
> Do we need this new set of KSP-specific functions for manipulating tab
> levels? There isn't a KSPTypeCompare(), etc. I thought the convention
> within PETSc was that user-level APIs were usually exposed as type-specific
> routines, but developer-level stuff used PetscObject directly.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120607/99a527cd/attachment.html>