I'm currently considering a project to simulate the (Earth-seeing) coverage of 1 or more satellites over the course of a year. The point would be to compare how different orbits result in different amounts of coverage, both of the Earth's surface and objects placed there.

The code for this would be written using Golang, in an attempt to increase efficiency/speed of calculation over other languages like Python. As there aren't many orbital propagators for Golang, this would mean writing my own orbit propagation algorithm (both kinetic and kinematic), or using one of the few available ones, such as the SGP4-based go-satellite package. There would also be multi-processing involved.

As such, I'm trying to wrap my head around which orbit propagation methodology would be useful for this kind of simulation. Given that the simulation would be, well, simulating an entire year, errors would likely accumulate for any propagation method I choose. However, Fidelity should be high for short-term analysis, and reasonable for long-term. I'm also interested in what kind of CPU resource requirements are necessary for the different propagator models/methods/algorithms, too - I'd ideally not require a supercomputing cluster.

As such, my question is as the title stated it: how important is the choice I make in orbit propagation model for this kind of simulation what would really be the importance/magnitude of error, and which propagation method is best suited for this kind of thing?


I'm not an expert and this is not an expert answer, but these points may be helpful.

Don't even think about using SGP4, per my comments below this question and Wikipedia it's a circa 1980's clever approximation to get approximate state vectors within a few weeks of any given TLE's epoch. It's an approximator based on evolution of orbital elements, not a real propagator.

Orbital integration for a year is numerically pretty easy. It's not at all a stiff problem, most things are slowly varying unless you use a really high order gravity model. You could even implement a simple variable step size RK45, some higher order RK's and some canned numerical integrators available in Golang and compare them and I think you'll find that a few minutes on a laptop is all you need to run a year's worth of orbit propagation unless you have a complicated physical model for all of the small accelerations besides Earth's central field.

considering that laptops are gigaflops and Golang is C-like in speed; e.g. 10,000 flops per step with a 10 second step size, a year of propagation would only need 30 seconds at 1 gigaflop. However a gigaflop per laptop may be optimistic because it involves parallelized calculations (e.g. arrays) and to take advantage of that you might want to run several cases in parallel if you're really pinched for time.

But be sure to check your numerical integration technique against a symplectic integrator. For more on that see all the wonderful answers to What does “symplectic” mean in reference to numerical integrators, and does SciPy's odeint use them?

If you want to include general relativistic effects which are small but should be checked, see the answers to How to calculate the planets and moons beyond Newtons's gravitational force?

The real problem you have is in the model for all of those smaller accelerations.

For a longer discussion on these as well as a great discussion on the varieties of numerical integrators and how you might implement them I entheusiastically recommend anyone to look at Satellite Orbits; Models, Methods, Applications by Oliver Montenbruck and Eberhard Gill, Springer, 2000 which can also be found in google books and is discussed here and here. Also see answers to When calculating the future orbit of an artificial Earth satellite, is the Moon's gravity significant or insignificant?

  1. Gravity model; how lumpy of a gravity field are you going to use? Just J2, or several low order terms, or a larger set of spherical harmonics for the geopotential?
  2. Drag model; atmospheric drag is really hard to model accurately. You can get some simple drag coefficients from TLEs of similarly shaped objects, but remember that the Sun's activity heats the atmosphere, raising the density at LEO altitudes, and so drag is fundamentally unpredictable. No matter how good your model is, you will have to run several cases with different patterns of solar activity to see how much they change the orbit's altitude and therefore phase and therefore ground track.
  3. Sun and Moon: their gravitational effects will be small and you can probably add simple models for those by including their motion in your simulation.
  4. Sunlight's photon pressure: this will be small but not non-existent.

I think others may post answers or comments that recommend existing software you can run to just get a feel for the problem and also to check your calculations against.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.