[petsc-dev] TS Terminology

[Matthew Knepley]

On Fri, Oct 20, 2017 at 11:22 AM, Emil Constantinescu <emconsta at mcs.anl.gov>
wrote:

> On 10/20/17 9:11 AM, Matthew Knepley wrote:
>
>> On Fri, Oct 20, 2017 at 9:23 AM, Emil Constantinescu <
>> emconsta at mcs.anl.gov <mailto:emconsta at mcs.anl.gov>> wrote:
>>
>>     On 10/20/17 7:57 AM, Matthew Knepley wrote:
>>
>>         I am confused by some of the terminology in TS. At the top
>>         level, IFunction appears to mean the entire equation
>>
>>             F(u, u_t, x) = 0
>>
>>
>>     Matt, page 141 of the manual: F(t, u, u_t) = G(t, u), and not zero
>>     on the RHS side. To make the interface general we allow internally
>>     for F:= F(t, u, u_t) - G(t, u) and then F=0.
>>
>>
>> This is not "internal". Its the toplevel interface:
>>
>> https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273a
>> 76ad4152cddc2fd80a/src/ts/interface/ts.c?at=master&
>> fileviewer=file-view-default#ts.c-884
>>
>> It computes F - G.
>>
>
> That's what it should do in some cases. The user provides either ifunction
> or rhs funtion or both. The api to the solvers can take care of this stuff
> automatically - that's what I meant by internal. Different TS solvers can
> take different definitions of the funtions; e.g., imex need both, beuler
> can take ifuntion and/or rhs function but instead of writing beuler for
> both we choose the most general case (ifunction) and compose the functions
> accordingly. The F - G is transparent to the user. But somewhere the
> sausage needs to be made and I think that is the right level because that
> is least likely to change and least maintenance.
>

I know what it does. I looked at the code. You are missing the point here.

We cannot use the same word, IFunction, for two different things, F and
F-G. The argument that is is not user facing is complete bullshit.
The user inputs the points for ifunction, and can also call the toplevel
interface.

   Matt


> Emil
>
>     Matt
>>
>>     Emil
>>
>>     PS: Manual: PETSc 3.8 September 26, 2017
>>
>>         However, this appears to mean something different than ifunction
>>         at the function pointer level. Inside TSCompiteIFunction(), it
>>         uses both ifunction and rhsfunction. This makes it hard to
>>         understand how composition works. TSComputeRHS() is called
>>         inside TSComputeIFunction(), so if we want to reuse vectors it
>>         should not initialize the vector, but it seems like
>>         TSComputeIFunction() should initialize the vector since
>>         TSComputeIFunctionLocal() does.
>>
>>         What guarantees about initialization should we have?
>>
>>              Matt
>>
>>         --         What most experimenters take for granted before they
>> begin their
>>         experiments is infinitely more interesting than any results to
>>         which their experiments lead.
>>         -- Norbert Wiener
>>
>>         https://www.cse.buffalo.edu/~knepley/
>>         <https://www.cse.buffalo.edu/~knepley/>
>>         <http://www.caam.rice.edu/~mk51/ <http://www.caam.rice.edu/~mk51/
>> >>
>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171020/7aea2d35/attachment.html>