I’m propagating a satellite for a pretty long time (some months) in a sequential way: I iteratively propagate for one orbit until the final date is reached. I was wondering why the propagation seems to be slowing down as the iterations keep accumulating. The first few iterations are done almost simultaneously: after each propagation I have a print and the propagation is so fast that several prints are done basically at the same time. As the propagation goes on, the prints become less and less frequent, suggesting that the propagation is slowing down. Is there something that can be done to increase the speed or is this an intrinsic problem of propagating for long times?
This behaviour is even more relevant if the propagation includes an EphemerisGenerator. I thought EphemerisGenerator was only saving the last propagation done, so I thought it would not be affected by how many iterations were already done.
I’m gonna start by assuming they you don’t have an event detector or something else affecting the integration.
If you are using a fixed step scheme e.g. Runge Kutta 4, the integrations speed should remain pretty much the same. Except if your dynamics becomes slower to evaluate where the orbit drifts. But for example with Keplerian motion this doesn’t happen.
If you are using an adaptive step scheme like the Dormand Prince ones, the size is determined according to tolerances. The tighter they are, the smaller the steps will be to accommodate the level of precision you are basically requesting (although there is no guarantee).
If the integrator is initialized with a very small stepsize, the first few iterations will be very quick because the estimated error will be low enough and the steps will all be accepted. The adaptive scheme then tries to increase the size to speed up computations, until they become too big. Steps will then start being rejected and the size will be decreased, and so on. In a way, some calculations are lost because they were deemed not trustworthy.
I’ll let my fellow developers comment further (especially the ephemeris generator that I don’t know in details) or even correct me.
Edit: if you want speed and are not super exigent on the fidelity of the propagation, I would advise using a semi analytical propagator. Orekit includes the DSST model. With it you can safely have a stepsize equivalent to a few orbital revolutions.
I’m using an adaptive step-size integration scheme (DoPri853) and I set the initial stepsize to 1min. I didn’t think about the stepsize being rejected as a problem since my orbit is nearly circular, so I don’t really expect large variations in the stepsize (although I might be wrong about this). The propagation does consider a number of perturbations though (Sun and Moon 3rd body, tides, drag, SRP, and geopotential up to J4,4) as well as a series of low-thrust maneuvers (in total, about 1/3 of the orbit is subjected to thrust). However, if the forces were to be the cause of the problem, I would expect them to have the same impact across all iterations. Am I missing something?
I’m gonna start by assuming they you don’t have an event detector or something else affecting the integration.
Well, I assume the propagator is calling some event detectors to check when to actually start the firing of the maneuvers, but again, wouldn’t this be affecting the propagation speed at each iteration?
The ephemeris generators stores all states. It does so by storing the step interpolator that is used by the underlying ODE integrator itself, in order to use the full accuracy that was computed.
If your propagation time is long (several months), the memory consumption will be large.
The goal of the ephemeris generator is… to generate an ephemeris that will be usable afterwards so it really stores everything. IT is used for example if you need to go back and forth within the propagation time range, for example to locate some parts for post-processing. If you only need to save the last part of the propagation, you can either set up a step handler that just stores the interpolator for last step or store the final state given by the return value of the propagate method. If you don’t need the full ephemeris, avoid generating it.
In my case what I do is basically a while-loop that at each iteration propagates for one orbit. So you’re saying that the ephemeris generator will store the entire propagation from orbit 1 to orbit n? If that is the case, why can I only access the last orbit when I call the getGeneratedEphemeris() method? I was under the impression that it would store only the integration steps of the latest propagation, over-writing them when several propagations are called in sequence. I deduced this from the fact that if I call getGeneratedEphemeris().getPVCoordinates(date, frame) for a date that is outside the current propagation range but belongs to a previous orbit (which was computed at the previous iteration) Orekit returns an error stating that the date selected is out of the ephemeris range.
If you only need to save the last part of the propagation, you can either set up a step handler that just stores the interpolator for last step or store the final state given by the return value of the propagate method.
At the moment I’m not using an ephemeris generator and only using the final state computed by the propagation, but I think I might need it in the near future so I tested it and mentioned that the slowing-down effect is more evident.
The you should probably use a fixed step handler and run only one propagation that would call your step handler at regular dates.
Yes, this is how it should work. I didn’t realize you called propagate in a loop, because we almost never do that. Do you store the various ephemerides in a list or something like that? If you store them, they end up cluttering available memory. If you don’t do that, we have to think further in order to find what happens.
Does this mean you notice a slow-down even without ephemeris generation? This is a problem.
The you should probably use a fixed step handler and run only one propagation that would call your step handler at regular dates.
Thanks for the suggestion! I will try that out.
Do you store the various ephemerides in a list or something like that? If you store them, they end up cluttering available memory. If you don’t do that, we have to think further in order to find what happens.
No, I don’t. I create the ephemeris generator outside of the loop and then call it inside the loop (after the propagation for the current iteration) to fetch and interpolate the ephemeris.
Does this mean you notice a slow-down even without ephemeris generation? This is a problem.
Yes, even without the ephemeris generator the propagation slows down over time. However, I think I found the root of the problem. Each iteration also adds 2 firings. This means that by the end, the propagator is fed more than a thousand force models to deal with (and almost all of them are firings that are out of the current propagation range). If the propagator is checking all of them, that would explain why the runtime increases as the loop progresses. I’ll try to clear all the force models, re-add the natural perturbations, and add only the current firings and see if that prevents the runtime from increasing.
Edit: as expected, removing the past maneuvers was the solution to my issue. I believe this might also be the cause when I run the loop with the ephemeris generator. Sorry for the unnecessary troubles
Could you try creating a new generator and a new propagator at each iteration?
I tried again by removing all the unnecessary firings and the propagation is now fine. The runtime is slightly slower than the case without ephemeris generation, but that is totally expected. The underlying cause was therefore the increasing number of force models the propagator had to check at each iteration.
