> I want to say again how much I dislike ad hoc memory layouts through > contexts > and the like. We have a perfectly good layout descriptor (DM) that should > be used > to describe data layout. > > Why do you say ad-hoc memory layout? the design vector is an input, and users can decide to layout memory as they want. What do you propose? DMGetDesignVec()? DMGetDesignDM()?
> Matt > > >> >> > Users can do anything they want with the forward model context, but they >> > are not free to change the application context of the adjoints TS. Maybe >> > this should be improved by adding and extra slot to AdjointTSCtx to >> carry >> > over the user context (for the adjoint I mean)? >> >> Why do you need to own the application context for the adjoint TS, >> versus using the context parameters to TSSetRHSJacobian, etc. >> >> >> > https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d >> >> 46cf7cad52/src/ts/interface/tspdeconstrainedutils.c?at= >> >> stefano_zampini%2Ffeature-continuousadjoint&fileviewer=file- >> view-default# >> >> tspdeconstrainedutils.c-579 >> >> > >> >> > Here is how ex23.c uses it >> >> > >> >> > https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d >> >> 46cf7cad52/src/ts/examples/tutorials/ex23.c?at=stefano_zampi >> ni%2Ffeature- >> >> continuousadjoint&fileviewer=file-view-default#ex23.c-677 >> >> >> >> And yet you redo the scatter here instead of using what you stuffed >> into >> >> the context. If you needed to redo it for correctness, you'd also need >> >> to in every other function that accesses design parameters. >> >> >> > https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d >> >> 46cf7cad52/src/ts/examples/tutorials/ex23.c?at=stefano_zampi >> ni%2Ffeature- >> >> continuousadjoint&fileviewer=file-view-default#ex23.c-274 >> >> >> >> >> > This is a leftover from a previous version of the code (there's also a >> > comment) that was not using TSSetSetUpFromDesign and it's definitely not >> > needed. >> >> Comments that some lines of code can be deleted is a good sign that they >> should be deleted. >> >> >> >> > Both methods need the Jacobian of the DAE wrt the parameters: H >> >> >> > TSAdjointSetRHSJacobian(), S TSSetGradientDAE() >> >> >> > >> >> >> > Initial condition dependence on the parameters is implicitly >> computed >> >> in >> >> >> > Hong's code (limited to linear dependence on all the variables); >> >> >> >> >> >> How so? Once the user gets \lambda(time=0), they can apply the >> chain >> >> >> rule to produce any dependency on the parameter vector? >> >> >> >> >> >> Yes, the chain rule is implemented here >> >> > >> >> > https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d >> >> 46cf7cad52/src/ts/interface/tspdeconstrainedutils.c?at= >> >> stefano_zampini%2Ffeature-continuousadjoint&fileviewer=file- >> view-default# >> >> tspdeconstrainedutils.c-254 >> >> >> >> I know you have a callback for it, but Hong's interface is plenty >> >> functional for such systems, they just call that derivative instead of >> >> writing and registering a function to do that. >> >> >> > >> > I'm not saying HOng's interface is not functional. >> >> I was responding to your statement that "Initial condition dependence on >> the parameters is limited to linear dependence on all the variables" in >> his approach. General dependence is supported, the user is just >> expected to call it themselves rather than registering a callback that >> TS calls. >> >> > The initial condition gradients allow to automatize the process in >> > TSComputeObjectiveAndGradient(), TSComputeHessian(), and >> > MatMult_Propagator(). Anyway, the lambda variables are not modified by >> > AdjointTSComputeFinalGradient() (that adds the IC dependency) and >> > users can do whatever they want with them. >> > >> > I know you don't like TSComputeObjectiveAndGradient(), >> >> I don't have a problem with the concept but don't want to rely on it. >> I'd rather discuss how to unify interfaces for discrete and continuous >> adjoints and get a PR for it merged before adding higher level >> interfaces. >> >> > but it's a code that anyway users have to write to compute a gradient >> > of the DAE not arising from a PDAE. How can this be automatized for >> > PDAEs? Should we store the AdjointTS inside the model TS and use >> > TSGetAdjointTS(ts,&ts->adjts) with >> >> I see reasons for the adjoint TS to hold a reference to the forward TS, >> but not vice-versa. What is the use case for your proposal below? >> >> > TSGetAdjointTS(TS f,TS* a) { >> > if (!f->adjtts) TSCreateAdjointsTS(f,&f->adjts); >> > *a = f->adjts: >> > } >> > >> > and the corresponding Setter to allow users to do >> > >> > TSCreateAdjointTS(ts,&atts) >> > TSSetRHSJacobian(ats,...) >> > TSSetAdjointTS(ts,ats) >> > >> > or >> > >> > TSGetAdjointTS(ts,&atts) >> > TSSetRHSJacobian(ats,...) >> > >> > >> > -- >> > Stefano >> > > > > -- > 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/> > -- Stefano
