<br><br><div class="gmail_quote">On Tue, Feb 28, 2012 at 2:21 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 14:16, 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>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).</div>


</blockquote><div><br></div></div><div>The IFunction is a particular way of representing a (part of) a transient problem. Its arguments include the time and the time derivative. We have to make that clear somehow and I think naming it after TS is helpful. Otherwise I'll eventually just have a bunch of names (function, residual, rhsfunction, objective, gradient, jacobian, ijacobian, hessian) and not know which ones go together.</div>

</div></blockquote><div><br></div><div>That's why encapsulating the related functions and their linearizations, one (R,J) pair per DM, is helpful.</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 class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>  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></div></blockquote></div></div><br><div>Yes.</div>
</blockquote></div><br>