Huge Impact of SimulationTimeStep on Drag Results

[loufla]

Hello,
I'm currently trying to implement drag on a basilisk simulation. I noticed that there was a huge amount of variation in results based on the simulation time step setting.

I used the ScenarioDragDeorbit.py example, changed the starting altitude to 500 km, and increased the maximum amount of orbits.

This is the results for a 90 second timestep (the default for this simulation)

And this is the result for a 15 second timestep.

After the same amount of time, the simulation for 90 seconds fell off 7.5x more than the 15 second time-step one.
This difference felt very significant, I was wondering if any of you experienced it, or somehow fixed it, and if you had any insight on which is more accurate for long term (2-5 years) satellite orbit simulations.

Thank you.

[Mark2000]

Yes, RK4 fixed timestep integration methods have errors that are sensitive to timestep size (with it being a 4th order method, the errors are proportional to dt^4 on a per-timestep basis). Since an orbit with the drag perturbation - especially at low altitudes - is essentially an unstable system, the larger errors cascade more quickly, causing the faster deorbit. You should run your experiments with a small timestep for a truth-like performance, then increase the timestep until it diverges too far from the behavior you would expect to see. We know that at 500 km, we’d reasonably expect deorbit to take on the order of ~5 years, so the 15s dt could be close to reasonable.

[loufla]

Thank you very much ! I'll also try to implement a variable timestep solution using the scenario as a guide !