[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

On Sat, Feb 11, 2012 at 8:24 AM, Matthew Knepley <knepley at gmail.com> wrote:

> Barry is clearly right that each DM should produce a single Mat. However,
> the proposed 2 DM (or
> multiple DM) interface is just as clearly wrong. The 2 Mat interface
> exists so that a user can specify
> the system and preconditioning matrix. However, if the system matrix is
> missing, we take it from the
> DM.
>
> I think this should be our policy everywhere. The KSP and PC both have
> SetDM, so put different DMs
> in each one. As discussed, they have to be "compatible", but they generate
> different Mats. This is
> how we should treat auxiliary operators as well.
>

This sounds fine to me, but what's the API for doing this? You want to do
KSPSetDM() and PCSetDM(),
so that the user has to explicitly pull out the PC to set its DM?  That's
okay, but it doesn't match
KSPSetOperators(), which takes care of getting the PC out to set the matrix
on it.  I guess it's not a big
problem, or there could be a convenience method KSPSetDMs() in addition to
KSPSetDM() and PCSetDM().
It's against our general rule of allowing the same thing to happen to
different ways.

Dmitry.


>
> This solution, however, does not solve our code optimization problems.
> First, we need DMs to be
> lightweight. I think Jed is right that they can share topology in the
> background for now, until we have
> an example where it needs to be explicit. Second, how can multiple DMs
> share assembly information.
> This does not just apply to KSP/PC matrices, since you can make the same
> argument for auxiliary
> operators (like the Laplacian on the pressure mesh). It seems like we want
> a system can group up the
> formation of DM operators when the control flow part of the code knows it
> needs them at the same time.
> Our abstractions for assembly are still quite weak, so I think we need
> examples of what they would share.
> My first thought is intermediate element calculations, such as stress from
> strain. I still do not see the
> nice way to make this happen, so I would keep them split up until we have
> a better idea.
>
>    Matt
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120211/ea98b809/attachment.html>