On 10/20/17 11:06 AM, Matthew Knepley wrote:
On Fri, Oct 20, 2017 at 11:58 AM, Emil Constantinescu
<[email protected] <mailto:[email protected]>> wrote:
On 10/20/17 10:43 AM, Matthew Knepley wrote:
On Fri, Oct 20, 2017 at 11:22 AM, Emil Constantinescu
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 10/20/17 9:11 AM, Matthew Knepley wrote:
On Fri, Oct 20, 2017 at 9:23 AM, Emil Constantinescu
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> 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/>
