I wanna control the burns purely via propulsion. That means, I’m adding 1 Maneuver ForceModel per thruster right at the beginning of the propagation and then as the objects are propagated there is some logic that triggers/stops the thruster(s).
Right now I’m doing it in a way, where my propulsion object has two fields: burnStartDate and burnStopDate. Initially they are both null and when the thruster gets triggered the burnStartDate gets set, when the burn stops, the burnStopDate gets set. The maneuverStart/Stop triggers are calculated against those values respectively (null is handled by returning a “large” negative number). When I need to trigger another maneuver, I simply rewrite the burnStartDate with the new date.
I understand, that this creates a limitation for back-propagation as I loose the information on past burns. That should be solvable by using TimeSpanMap for storing the burning/not burning states. I’m more wandering if this might be somehow influence the STM and make the propagation less precise.
You should beware that the numerical integrator calls the force models several times per step, and not always in chronological order (it goes back and forth within one step). This is even more complicated when the propagator is trying to locate an event as it will bracket the event date and then reduce the bracketing interval.
So if you store some state within the force model (like the burn status) without taking care of that, you may get weird behavior. TimeSpanMap is really your friend here, as it will take care of transitions. If the integrator wanders around the trigger date, it will get the proper status each time.
Hi Luc, thanks for the answer. Except for the TimeSpanMap, the propulsion model should be stateless, so simply calculates thrust and mass flow rate based on time or the elapsed time (calculated from the timeSpan.startDate) in case of propulsion model with a ramp-Up/down phase.
Btw. I just noticed the Profile based maneuver that came with version 12.0. In my implementation I was simply providing a transfer function that returned the relevant values based on elapsed time. In your implementation you are basing that on profiles. Is that so the propagator is forced “notice” the ramp-up/down phase, should it be rather short?
I understand. My question is rather actually about the oposite. I mean if it’s really short. Because otherwise I could simply use profile function based on elapsed time. So in every propagation step the thrust would be based on the calculated value. Which is basically what is being done in the PolynomialThrustSegment (if I understand correctly) but there would be no need for the profiles.
The only reason I see for the profiles is that the ramp-up time is too short and propagation step could simply “miss” it.
If it is short, using a step function (on/off) would be enough. The profiles are relevant only if the propulsion system either needs a warm-up or if it is indeed variable-thrust and in both case when the duration is larger than the step size.