<div class="gmail_quote">On Fri, Feb 10, 2012 at 17:24, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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 id=":3f">The reason I don't like having the single DM doing this is that one could use very different beasties to do the true Jacobian and preconditioner (not just a simple stencil change) and shoving that stuff into a single DM is unnatural. For example true problem is on an unstructured grid, preconditioner problem on a simplier structured grid.<br>
</div></blockquote><div><br></div><div>This particular example would normally make the Jacobian and preconditioner operator operate on different spaces (different sizes and different meanings). Or do you mean that the preconditioning matrix includes the restriction and interpolation from the "easier" grid? This makes sense, but it's probably a composition of matrices instead of being directly assembled.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3f"><div class="im">
<br>
><br>
> Lots of functions get messy if the DM has multiple ways to do something. Should DMCreateLocalVector() use the full stencil or the preconditioning stencil, what should DMGlobalToLocalBegin() be updating, etc.<br>
><br>
> Barry's solution of having separate DMs sounds cleaner to me, at least modulo needing conventions about which DM on which to PetscObjectCompose() things needed by certain callbacks (e.g. in the FAS with TS stuff I'm doing).<br>

<br>
</div>   Clean that up and provide a formal way to do those callbacks that don't use kludgy PetscObjectCompose() or PetscObjectComposeFunction()<br></div></blockquote><div><br></div><div>Okay, we need to sort this out because it's going to be a recurring theme with outer contexts doing UQ, optimization, and the like. These nested outer layers need some level-dependent auxiliary storage. But they don't know the levels in advance because the inner loop (SNESFAS) is constructing that. So SNES coarsens the DM and calls back on levels.</div>
<div><br></div><div>I don't think we want to make "coarsen" operations that we associate with the residual and Jacobian evaluation routines, having the DM responsible for coarsening (and restricting auxiliary information) makes more sense to me. Are we to call this on both DMs? Should one DM hold links to the "related" DMs?</div>
<div><br></div><div>Since the DM (and SNES, etc) do not know what auxiliary information the user wants to cache, PetscObjectCompose() seems like a reasonable method. Assuming any more structure is probably harmful.</div><div>
<br></div><div>Do you have suggestions for a more robust approach?</div></div>