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

[Jed Brown]

Stefano Zampini <stefano.zampini at gmail.com> writes:

>>
>> It'd have to be TSAddObjective if you're building a list.  Convention is
>> that Set replaces what might have been there before.
>>
>>
> Fair enough
>
>
>> In case of multiple objectives, there may be a performance reason to
>> amortize evaluation of several at once, though the list interface is
>> convenient.  Consider common objectives being quantities like lift and
>> drag on different surfaces of a fluids simulation or stress/strain at
>> certain critical joints in a structure.  Although these have some
>> locality, it's reasonable to assume that state dependence will have
>> quickly become global, thus make no attempt to handle sparse
>> representations of the adjoint vectors lambda.
>>
>>
> I don't get this comment. Is it related with multi-objective optimization
> (e.g. Pareto)?

Adjoints are usually preferred any time you are differentiating a small
number of output variables with respect to a large number of inputs.  It
could be for multi-objective optimization, but it's every bit as
relevant for physical sensitivities.

>> How are parameters accessed in TSComputeRHSFunction?  It looks like
>> they're coming out of the context.  Why should this be different?  (If
>> parameters need to go into a Vec, we could do that, but it comes at a
>> readability and possibly parallel cost if the global Vec needs to be
>> communicated to local vectors.)
>>
>>
> design paramaters are fixed troughout an adjoint/tlm run. They can be
> communicated locally once at the beginning of the run.
> This is what TSSetUpFromDesign and TSSetSetUpFromDesign are supposed to
> handle, if I get your comment.

My point is that users currently get design parameters out of the
context when evaluating their RHSFunction and friends.  If that is the
endorsed way to access design variables, then your new function doesn't
need to pass the vector.  If you need to pass the parameter vector in
that one function, instead of obtaining them from the context, then
you'd need to pass the parameter vector everywhere and discourage using
the context for active design variables.  I think there are merits to
both approaches, but it absolutely needs to be consistent.

> https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d46cf7cad52/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/c2e9112e7fdfd89985f9ffc4d68b0d46cf7cad52/src/ts/examples/tutorials/ex23.c?at=stefano_zampini%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/c2e9112e7fdfd89985f9ffc4d68b0d46cf7cad52/src/ts/examples/tutorials/ex23.c?at=stefano_zampini%2Ffeature-continuousadjoint&fileviewer=file-view-default#ex23.c-274

>> > 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/c2e9112e7fdfd89985f9ffc4d68b0d46cf7cad52/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.