Decouple force model management from numerical propagators

Dear community,

I am currently using Orekit for maneuver optimization purposes. After some use and source code diving I feel that force models should be handled outside numerical propagators thus allowing for more code reusability.

Instead of adding several force models to the propagator, the user would only introduce a single instance of a complex force model (whose class I will refer to as CompoundForceModel for the rest of this post). CompoundForceModel would extend the AbstractForceModel class and the propagator would only accept one force model through getForceModel(ForceModel model) and setForceModel(ForceModel model) methods, instead of modifying the existing force model by adding or removing ForceModel instances. The desired force model should be injected to the propagator through its constructor, making it always a conscious decision. All the checks that the propagator has to do regarding its force models would be outsourced to CompoundForceModel:

  • Ensuring that at least one of its sub models is a gravitational model
  • Adding/Removing individual force models

By restricting the number of force models introduced to the propagator to one, force model management and propagation would be decoupled. As the propagator would only handle one ForceModel instance at a time, the NumericalPropagator class size would be reduced significantly. Currently, the user can do what I am proposing by creating its own custom force model (which expands ForceModel) and adding it as the only instance to the propagator. However, it feels like the class NumericalPropagator is larger than strictly necessary which can make it difficult to maintain in the future. There are some issues such as how to ensure that ForceModel introduced to the propagator includes at least one gravitational model that should be tackled. However, the propagator should not handle those issues as it works with ForceModel instances in the first place.

As I am fairly new to Orekit, I am oblivious to the reasons behind the current implementation or if the code refactorization I am proposing is worth the effort. In my opinion, the cleaner and smaller the API the easier it is for new (and veterans) users to work. I would like to know Orekit developers' opinions before elaborating further on this topic.

Kind regards,
Sergio

This seems a good suggestion to me, +1.