[petsc-dev] Discussion about time-dependent optimization moved from PR

[Stefano Zampini]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171017/7f21a000/attachment.html>