ConstantThrustManeuvers in DSSTPropagator

Hello everyone,

I’m trying to include maneuvers in my DSSTPropagator. By looking on the forum I found this and this old topics, both mentioning the AbstractGaussianContribution class. I think I managed to successfully implement the equivalent Python class PythonAbstractGaussianContribution. Indeed, the code runs, however, I think that the results I obtain are wrong. In particular, I have doubts about the getLLimits method. From what I understand, this method is supposed to return the true longitude interval over which the force has to be averaged, so I imagine this interval should coincide with the interval over which the maneuver actually takes place.

As a first attempt, to compute these boundaries, I’m using a numerical propagator that propagates only the manevuer. These values are then passed to the DSSTManeuver during construction as DSSTConstantThrustManeuver(maneuver, Lv1, Lv2) and retrieved by the getLLimits method. This image shows the results (SMA, ecc and inc) obtained from a numerical propagator and the DSST one:
oscVSmean

As you can see, the maneuver is indeed accounted for, but the results are in my opinion very wrong.
I also tried setting Lv2 = Lv1 + 2*pi, and the results are again really weird:
oscVSmean1

As you can see, now the mean SMA is correct, but there is no effect on the eccentricity.
Any suggestions?

Hi @Emiliano,

This is a very nice (but hard) feature you’re developing right now!
This looks like a huge maneuver you’re implementing on a short arc though.
It does look almost instantaneous on your graphs :wink:

Could you share your code so we can re-run it on our side?

My guess is that in case 1 the semi-major axis maneuver changes the initial orbit so that Lv2 is reached before you expect it to be reached and the maneuver stops.
But I may very well be wrong.

Hello everyone;

Concerning the effect of the “averaged maneuver” on eccentricity: maybe you are averaging the de/dt on a symmetric interval which yields no net effect ?

All the best,
Andrea

Hello @MaximeJ, sorry for the delayed reply :sweat_smile:

The maneuver is indeed pretty large, it’s a 10 minutes 10 N maneuver. The reason I tried such large value for thrust is so that I could actually see the effect with just one maneuver.
Thank you for your help!

These are the file to run this test-case
dsstManeuverTest.py (7.9 KB)
MyDSSTManuever.py (1.2 KB)

Hello @andfio,

I’m not really sure how the averaging of the DSST works, but from a physical point of view I don’t think that’s the case because even if the averaging interval were symmetric, the de/dt term shouldn’t integrate to zero (or at least that’s what I’d expect) since the firing is in the tangential direction and the duration is significantly smaller than the orbital period.

Update: I also tried to compare the results of the osculating DSST propagation with the ones from the numerical propagation

Case 1
oscVSosc

Case 2
oscVSosc1

In both cases there is an effect on the inclination which I don’t understand where’s coming from (the maneuver is aligned with the velocity), but more importantly, the DSST osculating elements are far from the values returned by the mean propagation.

Hi @Emiliano,

There is a known bug with event handling and DSST in osculating parameters (see issue 834).

It turns out I just added some information on it yesterday while trying to use RESET_STATE in an event detector.

I think that you shouldn’t try to use ConstantThrustManeuver and DateBasedManeuverTriggers with a DSST osculating until this bug is fixed (since these triggers use RESET_STATE under the hood).

Hope this helps,
Maxime

Hi @MaximeJ do you know if the bugs regarding DSST maneuvers have been fixed? I have tried implementing a custom DSST maneuver along with a custom propulsion model class and for what ever values I return for getLLimits the maneuver doesn’t seem to occur.

Hi @emery,

No, unfortunately, bug 834 hasn’t been fixed yet… It’s a tricky one I think.
Contributions are always welcome !! :wink:

I’m not 100% sure your problem is related to this bug though…