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

[Barry Smith]

> On Oct 17, 2017, at 8:19 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Matthew Knepley <knepley at gmail.com> writes:
> 
>> On Tue, Oct 17, 2017 at 8:51 AM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>>> Matthew Knepley <knepley at gmail.com> writes:
>>> 
>>>>> It's a recipe for confusion.  Either the parameters are never passed
>>>>> explicitly or they are always passed explicitly and should not be stored
>>>>> redundantly in the context, thus perhaps enabling some sort of higher
>>>>> level analysis that dynamically changes parameter values.  I would go
>>>>> with the former for now.
>>>> 
>>>> 
>>>> 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.
>>> 
>>> This is an independent change from the adjoint work and I think it's out
>>> of scope right now.  If we change it, it should go in its own PR.  I
>>> don't like having one PR with a smattering of non-essential changes to
>>> old interfaces bundled together with new conventions and new
>>> functionality.
>>> 
>> 
>> My understanding was that this discussion is not about a particular
>> PR, but about the interface we should have for sensitivity and optimal
>> control.
> 
> Sure, but changing the way parameters are passed isn't an essential part
> of the adjoint interface.  This particular debate spawned from Stefano's
> claim that passing the parameter vector to one of his functions was a
> feature of his interface relative to Hong's.  I replied that it was an
> inconsistency -- we should either change all interfaces to pass
> parameter vectors explicitly or we never pass them.
> 
> But any such change would be orthogonal to the merits of TSAdjointSolve
> versus TSCreateAdjointTS.  Indeed, discussion of how parameters are
> accessed is derailing the present discussion from this crucial
> difference in interfaces.  Let's cut it out of the current thread.
> 
> I want to hear rationale for TSAdjointSolve() or a plan for refactoring
> those algorithms into TSCreateAdjointTS().

   Yes, we are waiting for Hong to provide his proposed API.

   BTW: Stefano has not really submitted a proposed API as I requested, just some minor explanation of his current API and minor changes.

  Barry

> 
>>> Putting the parameters in a vector would enable finite differencing of
>>> the RHSFunction to obtain its dependence on parameters.  That might have
>>> high (non-scalable in number of parameters) cost, but would be less
>>> expensive than finite differencing an entire model.  Consider the
>>> scenario of 100 parameters and 1e6 state variables (at each time step).
>>> If we have the ability to apply the transpose of the Jacobian with
>>> respect to model state, we could run an adjoint simulation and only need
>>> 100 RHSFunction evaluations per stage, rather than 100 solves.
>>> 
>> 
>> I am not sure of the point of the above paragraph. Saying the point rather
>> than implying
>> the point helps me.
> 
> It is a potential functional case for making the parameter vector an
> explicit argument.