<br><br><div class="gmail_quote">On Tue, Feb 28, 2012 at 1:24 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 Tue, Feb 28, 2012 at 12:13, 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>But this is what is causing the trouble. Vecs need to hold a DM to tell them how to write themselves, but DMs need</div><div>those Vecs to pass to sovlers. These are very different jobs, and thus cause loops.</div></blockquote>


</div><br></div><div>Most possible loops are managed by deterministic ordering of destruction. Work vectors are counted. If the only problem we need to solve is reference count cycle analysis for PetscObjectCompose, we can do that.</div>


<div><br></div><div><br></div><div>It sounds like at present, nobody has complained loudly about DM becoming the one-stop place for defining the problem to be solved (at least the nonlinear problem). Is that true? So do we move DMSetFunction() to DMSetSNESFunction() and add DMSetTSIFunction(), etc? </div>

</blockquote><div><br></div><div>I don't understand the need for multiple function evaluation routines and their explicit naming.</div><div>I think the situation here is completely analogous to the situation with matrices: I thought we agreed that each DM would be capable of generating a single matrix, the "Jacobian", rather than multiple matrices like J and J_pre, and that the different necessary matrices (again, e.g., J and J_pre) would instead be produced by their respective DMs -- the KSP DM and the PC DM, so to speak.  These subDMs would be pulled out of the SNES DM and passed to the corresponding KSP and PC objects.  Thus, a DM encapsulates a single "problem", and if we want to get a different problem -- the "exact" linearization of the original, for example -- we extract the KSP DM;  likewise, PC DM is an approximate linearization, and so on.</div>

<div><br></div><div>I don't think TS is any different -- we can have the TSI DM (maybe under a better name), which could have DMFormFunction encapsulating the IFunction (and, incidentally, a linearization encapsulating the mass matrix), etc.  The situation with splitting the problem into subdomains or subfields -- with DMs encapsulating these subproblems -- is completely analogous.  And if we really wanted to eliminate the dependence on SNES, KSP, TS, etc. -- even the logical dependence in the names of the functions calls like DMGetKSPDM --  we could resort to object composition.</div>

<div><br></div><div>In short -- I'm for each DM having one function (DMFormFunction or, better, DMFormResidual) and one matrix (DMFormJacobian) -- *a* linearization of the residual.  All other functions and matrices are obtained from the corresponding subDMs.</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>To avoid the dependency loop, those methods would actually live in src/snes and src/ts, but their argument would be a DM. The actual evaluation context for SNES would be composed with the DM, so it wouldn't actually reside in _p_DM.</div>


<div><br></div><div>Do we preserve SNESSetFunction() which would do SNESGetDM() and DMSetSNESFunction(). If no DM had been set, SNESGetDM() would create a dummy DM just as a place to attach its containers.</div><div><br>

</div>
<div>The DMComputeSNESFunction() would always be called by SNESComputeFunction(). If the DM was just the dummy, it would call straight through to the user's implementation, even forwarding the SNES along as the context. If the user had called DMSetSNESFunction() (or DMDASetLocalSNESFunction(), etc), that version would be called. (This is similar to current logic, but dispatch _always_ goes through some DM, even if it's just a dummy to hold function pointers.)</div>


</blockquote></div><br>