<br><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 11:11 AM, 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 Mon, Feb 27, 2012 at 10:55, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@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>Why is a nonlinear problem not part of the DM interface?  In my mind a DM encapsulates a problem, that also knows</div><div>how to linearize/split/coarsen/refine itself by returning the corresponding subDMs.  </div>

</blockquote>
</div><br></div><div>SNES depends on DM, not the other way around.</div><div><br></div><div>In some cases, the callback needs access to the TS or SNES because it is doing some configuration or wants to hack in some logic. The DM callbacks don't pass that parameter on. If they did pass it on, that part of the interface could not sit in src/dm.</div>

</blockquote><div><br></div><div>I agree that DM shouldn't depend on SNES or TS -- there is some awkwardness of a similar kind in libMesh.</div><div>One way around this ould be to have SNESSetUp proess the (possibly changed) DM settings before every solve.</div>

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