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>