PythonOrekitFixedStepHandler (Without final date)

Hi everyone!

I’m trying to propagate using a step handler added to the propagator and I wanted to know if it is possible to propagate without a final date. I mean, I want to propagate until the satellite reaches a certain altitude that will be checked with an AltitudeDetector. Is it always the final date a requirement for the .propagate method?

Thanks in advance,


Hi Verónica

This use case is a classical one for lifetime analysis: estimating when the satellite will reach typically 100km altitude, at which time it will fall within the next orbit.

You must set up an end date, but you can user either AbsoluteDate.FUTURE_INFINITY or some date really far in the future (say 100 years), and set the event handler of the altitude detector to stop when the event occurs, for example using the predefined StopOnEvent handler.


Hi @luc

Thank you for the fast reply!

I’m using an Altitude Detector and I have seen some strange behaviour:

When I set the altitude detector to 100km, it does not stop but when I set it to 300km it stops.

Do you know why this is happening?

Thank you in advance


What’s your initial orbit ?
And how did you configured the force models? Especially the drag effect (if you have/need one) since it contributes a lot in reducing the satellite altitude


Mi initial orbit comes from a TLE:

tle_propagator = TLEPropagator.selectExtrapolator(mytle)
tle_orbit_cart = tle_propagator.getInitialState().getPVCoordinates(J2000)
SatInitialState = KeplerianOrbit(tle_orbit_cart, J2000, mytle.getDate(), mu)
initialState = SpacecraftState(SatInitialState, float(mass))
integrator = ClassicalRungeKuttaIntegrator(2 * SatInitialState.getKeplerianPeriod())
propagator = DSSTPropagator(integrator, PropagationType.OSCULATING)
propagator.setInitialState(initialState, PropagationType.OSCULATING)

The drag effect is:

# Atmospheric Drag
atmo_data = MarshallSolarActivityFutureEstimation(MarshallSolarActivityFutureEstimation.DEFAULT_SUPPORTED_NAMES,
sun = CelestialBodyFactory.getSun()
atm = NRLMSISE00(atmo_data, sun, earth)
isotropic_drag = IsotropicDrag(cs, cd)
drag_force = DragForce(atm, isotropic_drag)
propagator.addForceModel(DSSTAtmosphericDrag(drag_force, mu))

Many thanks in advance!

In fact, I need the values of these elements :slight_smile:
Could you give us the values of initialState, cs, and cd?

I think you can increase the integration step. 10 * SatInitialState.getKeplerianPeriod() is OK. Especially in that case because the propagation will stop based on an event detection. So, it can take some time.




a: 6822426.131230648; e: 0.0022658304298223872; i: 2.5932843862395902; pa: -4.71209197501259; raan: 104.32514395056107; v: 5.407069928971303

cs = 20.967083816193547 m^2

cd = 0.07730892332806577

I will try increasing the integration step. Thank you!

The cd value looks small. How did you get it?

I have obtained it from the B* of the TLE as following:

Cd = B*·2·m/(cs*rho)

B* = 0.39152e-3
m = 352 kg
cs = 20.967083816193547 m^2
rho = 0.1570 kg/m^3

I don’t know how Celetrak estimate the B* value and how much we can trust the value in the TLE to determine a Cd…
I think your problem is because Cd is small. So the drag effect has a small impact and the satellite altitude reduce slowly.
Could you try with a Cd value of 1.0?

I see what you mean…

I have seen that in CelesTrak: "FAQs: Two-Line Element Set Format" they estimate the drag coefficient with the B* parameter of a TLE.

Do you know how can I estimate the drag coefficient? Or is it estimated during orbit determination?

I have tried it with a Cd = 1 and it does not stop at 100km. Nevertheless, I have tried at 200 km and it stops…

Estimate drag drag coefficient is very difficult. Mainly because of the uncertainties of the solar activity. It can be estimated during an orbit determination. But I don’t know if it’s the method employed to compute TLE’s B*.

Did you use AbsoluteDate.FUTURE_INFINITY as recommended by Luc. I’m surprised that the propagation doesn’t stop for 100km.

I assume the propagation does not stop because of the step size of the integrator.

I have tried another approach changing the DSST to a Numerical Propagator and it works better now.

Thank you very much!