<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 5:00 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><div class="gmail_quote">On Fri, Feb 10, 2012 at 16:56, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I realize that since the DMs may often share "the grid information" and only be different in the stencil width or box type or something Jed (or maybe it is Matt) is going to get all upset that their are two DMs with common information sometimes. My response is "get over it"   :-).</blockquote>


</div><br></div><div>Lots of objects share PetscLayouts, ISLocalToGlobalMappings, etc., without forcing this sharing on users (or, in most cases, even exposing the existence of these shared objects to the user). I think DM should work the same way.</div>


<div><br></div><div>In this case, we are interpreting Vecs as being part of both spaces. I'm less keen on that, but it's not a deal breaker.</div><div><br></div><div>What about DMDAFormJacobianLocal()? Should it have both matrices? How does the user manage the two DMs if they want to assemble both matrices in the same mesh traversal?</div>

</blockquote><div><br></div><div>I think it's completely natural for a DM to assemble two operators -- the discretizations for the two are likely to be related anyway -- as soon as we decide that it's natural for KSP to take in two matrices and, more importantly, for the callback set with DMSetJacobian() to compute two matrices: if a DM knows how to compute  two "Jacobians", why wouldn't it know how to create/preallocate the two corresponding matrices?</div>

<div><br></div><div>Dmitry.</div></div><br>