Extension of (Field)ImpulseManeuver

Hi all,

I propose that ImpulseManeuver takes instead of a fixed Vector3D a so-called ImpulseProvider as input.
It would take the SpacecraftState before the maneuver and the attitude override (can be null), whilst returning a Vector3D. It’s not the best design I admit but probably the less disruptive, as only the getDeltaVSat method would disappear and be replaced by a new getter. The old constructor will be preserved and a new one will be added.

The two applications that it would enable with a single instance are:

  • inclination change at the nodes since the direction varies if it’s ascending or descending
  • with a DateDetector and multiple dates for different deltaVs, it would be way more computationally efficient as the propagator struggles with hundreds of detectors

Thoughts?

Cheers,
Romain.

1 Like

Hi @Serrof,

That’s a good idea. I did struggle with the multiple-dates efficiency problem and had to design a specific class to improve performance. Using a single date detector is indeed way faster.
I guess your proposition would fix that issue natively.
So +1 for opening this feature and keeping the old interfaces alive!

Cheers,
Maxime

This seems good to me and it is a clean design.
I would even go further and remove the old API to avoid having multiple constructors, as we are heading to a major release anyway, it can be done.

About that, we could deprecate it and remove it in a future major version.
Removing the old API will definitely break many systems. I think it’s better if we can ease the gap of adopting a major version, v12 was hard enough to adopt for complex systems

1 Like

OK then, keep this API for a while

I 100% agree with @MaximeJ remarks.

Adopting version 12.0 was very painful because it contained many API changes in low-level Orekit functions (event detection, Earth modelling in propagation models, etc.).
Impose a new major version with API breaks in basic Orekit functions shortly after the previous major release is, in my opinion, a very bad idea. Especially if there is a possibility to maintain the old API.

A major release does not offer all liberties! There are operating systems in version 12.X that will not upgrade their Orekit version because it requires too much effort (and money).

We need to be vigilant about major version, which is not the case currently.

Regards,
Bryan, an Orekit user.

We have set up a thorough upgrade path to users for 13.0, so we are vigilant.