[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Jed Brown]

On Fri, Feb 10, 2012 at 17:24, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

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.


>
> >
> > 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.
> >
> > 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).
>
>    Clean that up and provide a formal way to do those callbacks that don't
> use kludgy PetscObjectCompose() or PetscObjectComposeFunction()
>

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.

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?

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.

Do you have suggestions for a more robust approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/6f37877d/attachment.html>