I am trying to introduce a constant thrust model to the DSST propagator, in order to simulate low-thrust electric propulsion maneuvers. This subject has been raised a few times in the past (see for example https://www.orekit.org/mailing-list-archives/orekit-users/msg00345.html), and two main possible solutions were proposed:
divide the maneuver in several smaller impulsive maneuvers;
create a new class that extends AbstractGaussianContribution and delegates to ConstantThrustManeuver.
I have implemented the first solution with good results. However, the computation time is increased considerably as the size of the discretization intervals is reduced, and for our application we would rather use a continuous acceleration model.
For the second solution, I wrote a class DSSTContinuousManeuver as described above and taking as reference the DSSTSolarRadiationPressure class. For now, I managed to make the DSST propagator run after adding the DSSTContinuousManeuver force model, but it doesn’t take into account the constant thrust (it just performs a free propagation). I suspect it has to do with the method getLLimits, which for now I left with [-PI, +PI], but I am not sure how to proceed. Do you have any ideas or advise?
The fact computation time is increased with a spit maneuver is expected. Impulsive maneuvers stop the propagator, change the state by adding a finite velocity increment, and start the propagator again. In the DSST case, starting a propagator has a lot of overhead.
For the continuous maneuver, I suggest you check the expected maneuver start and stop time and adjust the limits by converting this to orbital angles, hence ensuring the Gauss integrator that performs the averaging sees the correct acceleration. For the solar radiation pressure, the limits are computed according to the eclipse boundaries. For the drag, they are computed according to the spacecraft entering and leaving atmosphere. In your case, they should match thruster activation.
Hello, (I’m a colleague of pol.sola.romeu and work on the same project)
I have do some tests with using "ConstantThrustManeuver " and “AbstractGaussianContribution” and :
I have seen the two DateDetector objects created in the ConstantThrustManeuver object are not registred in the integrator so the ConstantThrustManeuver object is never “firing”
but if I force the “ConstantThrustManeuver” object with “firing=true”, it seems to work (I have not yet check the validity of result, but we see effect of thruster).
now I have to add the ON/OFF control and for this I think to add registration of “DateDetector objects” of ConstantThrustManeuver in integrator (rather than override getLLimits function). Do you thinks it should be possible ? (I’m surprised that the DateDetector objects are nor automatically registred in integrator)
Could you check if your DSST maneuver class, which extends DSSTForceModel does implement the getEventsDetectors and that the implementation does call the method with the same name
from the underlying ConstantThrustManeuver? It is the proper way to wire together the event detectors
with the propagator.
Once this is done, could you check if the propagator calls the setUpEventDetector in the internal class DSSTPropoagator.Main (in file DSSTPropagator.java)?
Note that even if adding a delegation to ConstantThrustManeuver.getEventsDetectors solves the automated firing, I still think the getLLimits should be adjusted to match firing period, otherwise the acceleration would be averaged with low accuracy, depending on how many points with firing on and how many points with firing off would be encountered by the integrator throughout the orbit.
I use orekit ConstantThrustManeuver as “DSSTForceModel” with just a modification “firing=true;” at initialisation.
it implements getEventsDetectors method
It seems the DSSTpropagator never call this getEventsDetectors() methods (checked using debugger) and so the two DateDetector objects created by ConstantThrustManeuver are never registred in integrator.
(Rq : it’s “my first steps” with Orekit : I may forget fundamental command to force this registration)
but the getDetectors() of the class extending “AbstractGaussianContribution” is called !
I will try to call getDetectors() of ConstantThrustManeuver (extends DSSTForceModel) here, and return the two date detectors generated by ConstantThrustManeuver
…
Edit :
Now my function AbstractGaussianContribution::getDetectors() call ConstantThrustManeuver::getDetectors() and that works … but
I have bug when Start date is close to start of propagation (thrust is never applied)
the “ConstantThrustManeuver::init()” function is never call, so problem when thurster is ON at start of propagation (thrust is never applied)
Now I will implement getLLimits() as you have said,
I have seen the two DateDetector objects created in the ConstantThrustManeuver object are not registred in the integrator so the ConstantThrustManeuver object is never “firing”
but if I force the “ConstantThrustManeuver” object with “firing=true”, it seems to work (I have not yet check the validity of result, but we see effect of thruster).
now I have to add the ON/OFF control and for this I think to add registration of “DateDetector objects” of ConstantThrustManeuver in integrator (rather than override getLLimits function). Do you thinks it should be possible ? (I’m surprised that the DateDetector objects are nor automatically registred in integrator)