Barry is clearly right that each DM should produce a single Mat. However, the proposed 2 DM (or<div>multiple DM) interface is just as clearly wrong. The 2 Mat interface exists so that a user can specify</div><div>the system and preconditioning matrix. However, if the system matrix is missing, we take it from the</div>
<div>DM.</div><div><div><br></div><div>I think this should be our policy everywhere. The KSP and PC both have SetDM, so put different DMs</div><div>in each one. As discussed, they have to be "compatible", but they generate different Mats. This is</div>
<div>how we should treat auxiliary operators as well.</div><div><br></div><div>This solution, however, does not solve our code optimization problems. First, we need DMs to be</div><div>lightweight. I think Jed is right that they can share topology in the background for now, until we have</div>
<div>an example where it needs to be explicit. Second, how can multiple DMs share assembly information.</div><div>This does not just apply to KSP/PC matrices, since you can make the same argument for auxiliary</div><div>operators (like the Laplacian on the pressure mesh). It seems like we want a system can group up the</div>
<div>formation of DM operators when the control flow part of the code knows it needs them at the same time.</div><div>Our abstractions for assembly are still quite weak, so I think we need examples of what they would share.</div>
<div>My first thought is intermediate element calculations, such as stress from strain. I still do not see the</div><div>nice way to make this happen, so I would keep them split up until we have a better idea.</div><div><br>
</div><div>   Matt</div><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>

</div>