[petsc-dev] TS Terminology

[Emil Constantinescu]

On 10/20/17 11:06 AM, Matthew Knepley wrote:
> On Fri, Oct 20, 2017 at 11:58 AM, Emil Constantinescu 
> <emconsta at mcs.anl.gov <mailto:emconsta at mcs.anl.gov>> wrote:
> 
>     On 10/20/17 10:43 AM, Matthew Knepley wrote:
> 
>         On Fri, Oct 20, 2017 at 11:22 AM, Emil Constantinescu
>         <emconsta at mcs.anl.gov <mailto:emconsta at mcs.anl.gov>
>         <mailto:emconsta at mcs.anl.gov <mailto: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>
>         <mailto:emconsta at mcs.anl.gov <mailto:emconsta at mcs.anl.gov>>
>                  <mailto:emconsta at mcs.anl.gov
>         <mailto:emconsta at mcs.anl.gov> <mailto: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/63ae3ecac3af8ce782273a76ad4152cddc2fd80a/src/ts/interface/ts.c?at=master&fileviewer=file-view-default#ts.c-884
>         <https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273a76ad4152cddc2fd80a/src/ts/interface/ts.c?at=master&fileviewer=file-view-default#ts.c-884>
>                 
>         <https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273a76ad4152cddc2fd80a/src/ts/interface/ts.c?at=master&fileviewer=file-view-default#ts.c-884
>         <https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273a76ad4152cddc2fd80a/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, we do not. IFunction is F(t,u_t,u), RHS function is G(t,u).
>     What we solve is F=G and not F=0. Do you doubt that?
> 
>     When the user specifies IFunction it is that F; when the user
>     specifies RHS it is that G.
> 
> 
> Nope. We use the word IFunction, specifically in the ifunction function 
> pointer to mean
> 
>    F
> 
> but we use the word IFunction, specifically in TSComputeIFunction, to mean
> 
>    F - G
> 
> And, no its visible to everyone, not just "TS developers".

Matt, that depends, if TS method is imex, then it computes just F, not 
F-G so your argument is not correct. If the method can do only implicit 
it computes F and subtracts G *if defined*. If the TS method can only do 
explicit and you define F then it fails.

Again, this has to do with the TS methods and PETSc doing the work for 
you of packing the functions in different ways.

Emil

>    Matt
> 
>     Now internally, because different solvers have different needs the
>     IFunction ... presented to the TS solver may look differently. This
>     is a design choice - if you are not a TS developer it should not
>     affect you.
> 
>     This is a design decision: if implemented at this level, we avoid
>     having every TS method be aware of the upper level functions.
> 
>     Emil
> 
> 
> 
> 
> 
> 
> -- 
> 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/>