<br><br><div class="gmail_quote">On Tue, Feb 28, 2012 at 2:06 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="gmail_quote"><div class="im">On Tue, Feb 28, 2012 at 13:52, 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>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. </div>


</blockquote><div><br></div></div><div>I'm concerned that this becomes insanity. A single TS might need RHSFunction, IFunction, and IJacobian. They might also partition terms differently for the functions and the Jacobian. Having different DMs seems awfully confusing. </div>

</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>


</blockquote></div></div><br><div>The interface is actually different for these (compare TSIFunction, a transient residual, to SNESFunction)</div>
</blockquote></div><br><div>Okay.  I would still refrain from calling these things by the class of the object consuming them.  DMFormFunction() and DMFormIFunction() seem fine, since these have a meaning independent of TS (although the DM has to then encode a transient problem).  But I don't like DMGetSNESFunction() any more than I like DMGetKSPJacobian() and DMGetPCJacobian().  </div>

<div><br></div><div>By the way, should we start using Residual instead of Function? </div><div><br></div><div>Dmitry.</div><div><br></div><div><br></div>