[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Matthew Knepley]

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 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/9eba54b2/attachment.html>