<br><br><div class="gmail_quote">On Sat, Feb 11, 2012 at 8:24 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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></blockquote><div><br></div><div>This sounds fine to me, but what's the API for doing this? You want to do KSPSetDM() and PCSetDM(), </div><div>so that the user has to explicitly pull out the PC to set its DM?  That's okay, but it doesn't match </div>

<div>KSPSetOperators(), which takes care of getting the PC out to set the matrix on it.  I guess it's not a big</div><div>problem, or there could be a convenience method KSPSetDMs() in addition to KSPSetDM() and PCSetDM().</div>

<div>It's against our general rule of allowing the same thing to happen to different ways.</div><div><br></div><div>Dmitry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<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 class="im"><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></div>
</blockquote></div><br>