If you built a nested fieldsplit and wanted to look at the ksp monitor output from all the levels of nesting, before this fix<div>the output would be extremely confusing.  This is because setting the tab level on a PCFIELDSPLIT's inner KSPs doesn't </div>

<div>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</div>

<div>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).</div>

<div>I guess we could make this call virtual by making PetscObjectIncrementTabLevel() etc. dispatch through a function pointer. </div><div><br></div><div>Finally, note that it is the KSP is giving its tab level to the DM, not the other way around.  </div>

<div>This is probably inconsequential, unless you view the DM.</div><div><br></div><div>Dmitry.</div><div><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 5:45 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Did we just adopt a new line formatting convention and nobody told me?</div><div><br></div><div><div><font face="courier new, monospace">          ierr = PetscObjectGetOptionsPrefix((PetscObject)(ilink->ksp),&prefix); CHKERRQ(ierr);</font></div>


<div><font face="courier new, monospace">          ierr = PetscObjectSetOptionsPrefix((PetscObject)(dms[i]), prefix);     CHKERRQ(ierr);</font></div><div><font face="courier new, monospace">          ierr = KSPSetDM(ilink->ksp, dms[i]);                                   CHKERRQ(ierr);</font></div>


<div><font face="courier new, monospace">          ierr = KSPSetDMActive(ilink->ksp, PETSC_FALSE);                        CHKERRQ(ierr);</font></div></div><div><font face="courier new, monospace">          ierr = PetscObjectIncrementTabLevel((PetscObject)dms[i],(PetscObject)ilink->ksp,0); CHKERRQ(ierr);</font></div>


<div><br></div><div><div><font face="courier new, monospace">        }</font></div><div><font face="courier new, monospace">        else {</font></div></div><div><div><br></div><div><font face="courier new, monospace">        if(jac->reset)  </font></div>


<div><font face="courier new, monospace">          SETERRQ(((PetscObject)pc)->comm,PETSC_ERR_SUP,"Cases not yet handled when PCReset() was used");</font></div></div><div><br></div><div>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).</div>


<div><br></div><div>Is the tab level above even correct? Why would the KSP tab level be expected to match the DM tab level?</div><div><br></div><div>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.</div>


<div><br></div>
</blockquote></div><br></div>