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