> On Oct 17, 2017, at 8:19 AM, Jed Brown <[email protected]> wrote: > > Matthew Knepley <[email protected]> writes: > >> On Tue, Oct 17, 2017 at 8:51 AM, Jed Brown <[email protected]> wrote: >> >>> Matthew Knepley <[email protected]> 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.
