Methods transformPVCoordinates in (Field)Transform wrap up a call to applyTo in (Field)AngularCoordinates. The thing is that more than half the lines of code (that gives you an idea of the corresponding computational load) in this are for the acceleration vector. But in many applications, one does not need the latter. A frequent one is computing the atmosphere’s velocity for the drag force.
An API-preserving solution is to add an other version of those methods with a boolean added as second argument, something like ignoreAcceleration. The existing signature will use a default False value so that nothing gets broken.
I think this echoes a broader discussion we should have on (TimeStamped)PVCoordinates and its Field equivalent, about the acceleration part and performance. But any architecture changes would be for Orekit 13 probably.
Thanks for the link Bryan, I didn’t know about the genesis of StaticTransform, which is one of the best recent addition in Orekit imho. What do you think @evan.ward ? Should we go on with your idea of KineticTransform? Ideally I would like to rework PVCoordinates because the fact that it can hide an acceleration is at best a nomenclature issue already raised here. But there’s no time to do it for Orekit 12 so I’m not sure what to do in the short term.
Has anyone an opinion on this? Introducing KinematicTransform represents some work while an additional signature for transformPVCoordinates is straightforward.
I still like the idea of a KinematicTransform form an API perspective. I didn’t implement that in the first cut because the performance gains from ignoring a when transforming pv were not as much as ignoring va when transforming p. I also won’t have time to implement it any time soon. So you’re welcome to take it on.
I agree there is a nomenclature issue with PV vs PVA. It would be nice to correct, but I haven’t done the work to see what we would gain from it. The propagators all return PVA with currently no way to make them only return P or PV. (That’s reasonable for numerical propagators, but with e.g. TLES often only position is needed.) So I’m not sure what performance improvement it would bring.
I should be able to implement KinematicTransform for the new minor release, yes. It’s definitely a more robust approach. And maybe you’ll find some time to review it?