On Fri, Oct 20, 2017 at 12:34 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: > > > On Fri, Oct 20, 2017 at 11:58 AM, Emil Constantinescu < > [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]>> 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]>>> > >>> 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 > >>> <https://bitbucket.org/petsc/petsc/src/63ae3ecac3af8ce782273 > >>> a76ad4152cddc2fd80a/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". > > The "imex" flag is part of the TSComputeIFunction interface. If that > flag is TRUE, then IFunction is exactly what the user provides. If > FALSE, then the RHSFunction is subtracted off. Should that be better > documented? > > We could make a new interface TSComputeIFunctionMaybeMinusRHSFunction() > but I don't think it's necessary. Without any such interface, the TS > implementations would each need to reproduce a bunch of vector and > matrix wrangling. > > Note that TSComputeIFunction is very much like SNESComputeFunction, > which includes > > if (snes->vec_rhs) { > ierr = VecAXPY(y,-1.0,snes->vec_rhs);CHKERRQ(ierr); > } > > Why haven't you complained about that? > Good point. I did not notice. This came up because the initialization of input vectors is inconsistent between TSComputeIFunction() and TSComputeIFunctionLocal(). The former does not zero the output vec, but the later does. 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/ <http://www.caam.rice.edu/~mk51/>
