On Mon, Feb 27, 2012 at 11:12 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So we still haven't resolved the issue. Let's start by deciding who owns the function pointers. Are we putting all the function pointers for SNES and TS into DM? If this is the right route, I can make a simple container DM that SNES and TS automatically allocate to store the pointers, so the current interface would continue to work, at least for a while.</blockquote>
<div><br></div><div>I like this because we are using DM for our equation abstraction. I think the dependency loops are due to refusal to</div><div>decompose the DM.</div><div><br></div><div>  Matt  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>What is the alternative?<div><div class="h5"><br><div><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 11:55, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">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><div class="gmail_quote">On Mon, Feb 27, 2012 at 11:48, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">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">
<div>? My signature for FormJacobianLocal(DM dm, Vec X, Mat Jac, AppCtx *user) definitely has a context, which is<div>required to have DM as the first member. We could require the solver as the second member.</div>
</div></blockquote></div><br></div><div>"My" is not the one in DM base. We are suffering some fragmentation because different DMs implement the local problem differently. I think it would mostly resolve the issues if the DM functions forwarded the SNES and TS on to the user, but that makes a dependency loop (unless that code does not live in DM; we can hack around it with void*).</div>


<div><br></div><div>Alternatively, we can make TS and SNES have PushDM() and PopDM() methods so the callback can be (SNES, Vec, Mat, void *ctx), but SNESGetDM() returns the correct DM. Maybe this is too confusing.</div><div>


<br></div><div>In any case, if we fix the DM callbacks, I would prefer to get rid of the ability for SNES and TS to hold their own callbacks. We can keep essentially the same user interface (though perhaps the DM argument would become explicit).</div>


</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><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>