I feel like the mass rate is pretty much the only first-order, time derivative that is not stored in (Field)SpacecraftState. You can find there the acceleration (or other their equivalent with orbital elements), the attitude rates and even derivatives of custom additional variables. So first of all it’s a bit strange, but I can also think of at least two applications for having the rate:
knowing at once if some thrusting is going on (non positive value).
improving the shiftedBy method since at the moment the mass stays constant
Thoughts?
I think it’s a good idea to store the mass derivatives if it’s lacking compared to other parameters derivatives.
I’m a bit afraid of this one. First of all, if you don’t know exactly when your maneuver is bound to stop then I don’t see the point of shifting the mass… but ok, I can see the usage when you’re fully aware of what you’re doing.
Then, if the user is not aware of the fact that the mass changing it can lead to huge errors, or exceptions (negative mass).
Anyway, since it’s changing a deep mechanism in Orekit that could break existing legacy software, I don’t think it should be planned for a minor release.
Many people used the shiftedBy method being aware that the mass was preserved. Changing this abruptly could cause many legacy software to break inexplicably.
Edit: looking a bit at the call hierarchy of the SpacecraftState.shiftedBy method I think it’s too dangerous to implement the mass change by default. It’s used everywhere in “exploration” methods (light time delays in measurements, shifts inside the g function of detectors or in handlers, etc.). I can see a dozen places where we’ll end up with a “negative mass” exception because the “exploration” mechanism went too far on a maneuver thrusting arc.
I suggest implementing a shiftedBy(double dt, boolean shiftMass), and the default version with shiftMass=false. That way it would be fully minor-compatible.
Thanks a lot for the analysis. I don’t mind at all waiting for a major release to modify shiftedBy. Although its use is supposed to be limited to small steps so I don’t think we’d get that many negative mass exceptions (and if we do it’s at best a documentation problem). And I’m not sure that having several signatures is a good idea for that method. But again it’s fine with me to leave that unchanged, as long as the rate becomes available via a getter.