I have noticed an odd behavior with the GetFirings method for Maneuver Triggers, where the boolean TimeSpanMap objects get overwritten with False values after successive propagation arcs. I do not know if this is the intended behavior, and I could have an issue in my implementation, though it does seem like a bug…
Here is generic example of what I am intending to do:
Setup Orekit Scenario (Numerical Propagator, Force Models…)
Setup a Low Thrust Maneuver #1 with ConfigurableLowThrustManeuver and StartStopEventsTrigger
Run Propagation from time[0] to time[1]
Setup a new Low Thrust Maneuver #2
Run Propagation from time[1] to time[2]
Plot from time[0] to time[2] to see that both maneuvers executed correctly
Use getFirings() to get boolean timeSpanMaps from time[0] to time[2] for Maneuvers #1 and #2
At this point this is where the bug is evident as the timeSpanMap for Maneuver #2 is correct, while the map for Maneuver #1 is overwritten by only False values.
Hopefully this adds clarity, and the simple work around has been to call getFirings() after each propagation and storing the boolean states, then merging each of these temporary variables after the final propagation arc is run. The only issue with this workaround is that I lose the benefits of the TimeSpanMaps in terms of memory usage and keeping the boolean states tracked to specific dates.
This method is called each time you call `NumericalPropagator.propagate(…)
Since Maneuver1 isn’t triggered from time[1] to time[2] then the map of firings stays false
Now no method can remove a single force model from a NumericalPropagator, if you think this would be a good addition, please open an issue on the Orekit forge.
Workarounds are:
Remove all force models with NumericalPropagator.removeForceModels() and add them all back without Maneuver1, but with Maneuver2
Use a NumericalPropagatorBuilder instead: before each propagation, reset the orbit with the latest spacecraft state, and build a new propagator on which you will add the maneuver adapted to this propagation arc.
That makes sense as to why this is happening then. I would like to avoid rebuilding the propagator as I could envision use cases where there are a lot of different maneuvers in a script, and this approach seems quite inefficient.
I have thought that the ability to remove specific force models from a propagator would be an extremely beneficial feature, and I am happy to submit a issue on the forge page for this.
I don’t know if that’s really a feature we want. If you need to change your dynamics, I advice you to recreate a propagator, it’s a safer habit. You can reuse the force models of a template object if you like. As Maxime mentioned there is also a native builder in Orekit, but it’s primarily aimed for orbit determination so maybe not the right thing for you.