I am wondering if we should flip the semantic of ParameterDriver.
At the beginning, drivers only held one value. Then a change was introduced to hold a TimeSpanMap (which really is two maps now, one for names and one for values), and adding a Span prefix too. This is cumbersome and in fact not used in many places. I wonder if we could go back to one name and value for one parameter driver, and just hold a TimeSpanMap of drivers where needed ?
A second evolution I am thinking of would be to have a Field version of ParemeterDriver This would be helpful for issue 1867.
I would love to have a fielded version of the parameter drivers, or a mechanism that would allow using either a field or a double parameter in the force models. That would for example allow to field the drag parameter without having to rewrite a drag force model entirely. But this latest behaviour may be hard to introduce in the code.
Why not, it seems indeed rarely used.
Was there a rationale to have two different maps. I remember a discussion where someone asked for the selection of particular span in the map, which is not possible right now.
I think the proper way would be to have a single map holding (value, name, selection).
Maybe it’s time to have a proper architecture for the drivers instead of a single object. But I suggest we hold any huge change for version 15. Version 14 is already long overdue.
So I would say do what is really necessary for issue-1867, but we should keep it small for now so that the release date doesn’t shift too much.
I’m a bit confused by the Field aspect.
In my understanding, one of ParameterDriver’s main thing is the orekit internal capability to define independent variables for the automatic differentiation when computing partial derivatives, which happens with the class Gradient. What’s the point of defining a Field version?