<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 20, 2017 at 12:34 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Fri, Oct 20, 2017 at 11:58 AM, Emil Constantinescu <<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a>><br>
> wrote:<br>
><br>
>> On 10/20/17 10:43 AM, Matthew Knepley wrote:<br>
>><br>
>>> On Fri, Oct 20, 2017 at 11:22 AM, Emil Constantinescu <<br>
>>> <a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a> <mailto:<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a>>> wrote:<br>
>>><br>
>>> On 10/20/17 9:11 AM, Matthew Knepley wrote:<br>
>>><br>
>>> On Fri, Oct 20, 2017 at 9:23 AM, Emil Constantinescu<br>
>>> <<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a> <mailto:<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a>><br>
>>> <mailto:<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a> <mailto:<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a>>><wbr>><br>
>>> wrote:<br>
>>><br>
>>> On 10/20/17 7:57 AM, Matthew Knepley wrote:<br>
>>><br>
>>> I am confused by some of the terminology in TS. At the<br>
>>> top<br>
>>> level, IFunction appears to mean the entire equation<br>
>>><br>
>>> F(u, u_t, x) = 0<br>
>>><br>
>>><br>
>>> Matt, page 141 of the manual: F(t, u, u_t) = G(t, u), and<br>
>>> not zero<br>
>>> on the RHS side. To make the interface general we allow<br>
>>> internally<br>
>>> for F:= F(t, u, u_t) - G(t, u) and then F=0.<br>
>>><br>
>>><br>
>>> This is not "internal". Its the toplevel interface:<br>
>>><br>
>>> <a href="https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273a" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/src/<wbr>63ae3ecac3af8ce782273a</a><br>
>>> 76ad4152cddc2fd80a/src/ts/<wbr>interface/ts.c?at=master&<br>
>>> fileviewer=file-view-default#<wbr>ts.c-884<br>
>>> <<a href="https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/src/<wbr>63ae3ecac3af8ce782273</a><br>
>>> a76ad4152cddc2fd80a/src/ts/<wbr>interface/ts.c?at=master&<br>
>>> fileviewer=file-view-default#<wbr>ts.c-884><br>
>>><br>
>>> It computes F - G.<br>
>>><br>
>>><br>
>>> That's what it should do in some cases. The user provides either<br>
>>> ifunction or rhs funtion or both. The api to the solvers can take<br>
>>> care of this stuff automatically - that's what I meant by internal.<br>
>>> Different TS solvers can take different definitions of the funtions;<br>
>>> e.g., imex need both, beuler can take ifuntion and/or rhs function<br>
>>> but instead of writing beuler for both we choose the most general<br>
>>> case (ifunction) and compose the functions accordingly. The F - G is<br>
>>> transparent to the user. But somewhere the sausage needs to be made<br>
>>> and I think that is the right level because that is least likely to<br>
>>> change and least maintenance.<br>
>>><br>
>>><br>
>>> I know what it does. I looked at the code. You are missing the point here.<br>
>>><br>
>>> We cannot use the same word, IFunction, for two different things, F and<br>
>>> F-G. The argument that is is not user facing is complete bullshit.<br>
>>> The user inputs the points for ifunction, and can also call the toplevel<br>
>>> interface.<br>
>>><br>
>><br>
>> Matt, we do not. IFunction is F(t,u_t,u), RHS function is G(t,u). What we<br>
>> solve is F=G and not F=0. Do you doubt that?<br>
>><br>
>> When the user specifies IFunction it is that F; when the user specifies<br>
>> RHS it is that G.<br>
>><br>
><br>
> Nope. We use the word IFunction, specifically in the ifunction function<br>
> pointer to mean<br>
><br>
> F<br>
><br>
> but we use the word IFunction, specifically in TSComputeIFunction, to mean<br>
><br>
> F - G<br>
><br>
> And, no its visible to everyone, not just "TS developers".<br>
<br>
</div></div>The "imex" flag is part of the TSComputeIFunction interface. If that<br>
flag is TRUE, then IFunction is exactly what the user provides. If<br>
FALSE, then the RHSFunction is subtracted off. Should that be better<br>
documented?<br>
<br>
We could make a new interface TSComputeIFunctionMaybeMinusRH<wbr>SFunction()<br>
but I don't think it's necessary. Without any such interface, the TS<br>
implementations would each need to reproduce a bunch of vector and<br>
matrix wrangling.<br>
<br>
Note that TSComputeIFunction is very much like SNESComputeFunction,<br>
which includes<br>
<br>
if (snes->vec_rhs) {<br>
ierr = VecAXPY(y,-1.0,snes->vec_rhs);<wbr>CHKERRQ(ierr);<br>
}<br>
<br>
Why haven't you complained about that?<br>
</blockquote></div><br>Good point. I did not notice. This came up because the initialization of input vectors is inconsistent</div><div class="gmail_extra">between TSComputeIFunction() and TSComputeIFunctionLocal(). The former does not zero the</div><div class="gmail_extra">output vec, but the later does.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> Matt<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>