[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] ESA space debris movie - Orekit under the hood


"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :
Cool. That seems like good performance too. Out of curiosity were the propagations multi-threaded or all occurring in the same thread? 

Thanks,

Everything was single thread. One of the unexpected challenge was that
Blender needs one file for each movie frame (i.e. each time step) containing
all objects at that time. Orekit computed trajectories for one object
throughout the time span and then switched to the next object. Opening and
closing thousands of files, appending a few bytes and closing them as
propagation ran was not an option. Keeping everything in memory before
writing the data was also not possible. We had to find some trade-off.
In fact, going this fast was more a data throughput problem than a
computation problem. At start, we expected a computation bottleneck, but the
bottleneck was rather the disk (it was a mechanical drive, not a SSD).

We also observed that computation for the active satellites was clearly
much slower than defunct or fragments. This was due to attitude modes:
yaw compensation in nadir pointing involves a lot of computation as we
very accurately compute the projection on ellipsoid, taking into
account the different curvatures (East-West and North-South), and the
time derivatives of the projection. Using only body center pointing or
even LOF aligned would certainly have been sufficient too. As computation
was fast enough, we didn't care to optimize it further, and it was also a
good stress test for the attitude modes.

best regards,
Luc



Best Regards,
Evan

On Fri, 2017-04-28 at 10:55 +0200, MAISONOBE Luc wrote:

Hi all,

You may have noticed the news published recently about the ESA
movie about space debris. The 2D version of the movie is here:
<https://www.youtube.com/watch?v=zT7typHkpVg>. The 3D version
is here: <https://www.youtube.com/watch?v=EzrMHWjQCtc>.

In case this is of interest for some of you, here are some background
information about how Orekit was used for generating data for the movie.

The movie was created for ESA by ID&Sense and ONiRiXel, with some help
from CS and the Orekit team. Orekit was used for all the trajectories
and attitude from GEO to LEO. I don't know how the L2 or Integral orbits
were generated, I only guess ephemerides were provided for these.

As realistic simulation was desired for the 16741 debris involved,
we wanted something better than Keplerian only and needed attitude
modelling. On the other hand, as a movie shows the trajectories at
Earth scale and as the time range covered by the simulation was short
(3 hours), tiny force models were not included. We arbitrarily limited
the force model to Earth gravity with degree and order 12 . This was
probably already overkill; degree 2 and order 0 would probably
have been sufficient. Earth orientation and Sun direction were
also provided by Orekit.

As the movie clearly depicts the GEO ring, navigation satellites
and also all active LEO (but here it is less clear as LEO is
overcrowded by uncontrolled debris), we wanted to have a proper
simulation of both attitude and solar arrays orientation. When
looking at the GEO ring for example, the alignment of solar
arrays for active satellites is obvious. For defunct spacecrafts
or other junk, we  wanted to show a tumbling mode, which is also
obvious for the rocket stage that appears near the GEO ring. We
used a set of predefined attitude modes (nadir pointing with
Yaw compensation for SSO, LOF aligned for GEO, random selection
between nadir pointing with yaw steering and LOF aligned for other
active satellites, fixed rate with random initial orientation and
random rotation rate vector for other bodies). For active satellites,
the solar arrays orientation was also computed on top of the attitude
and written to the generated output files.

The files generated were written as binary particles files that
were imported directly by Blender <https://www.blender.org/> (the
open source 3D creation suite).

The simulation involved 16741 real objects from a catalog provided
by ESA. The objects were classified as follows:

  - rocket bodies:    1688
  - mission related:  1055
  - active:            981
  - defunct:          2717
  - fragment:        10300

The active set included one weird object with a perigee below Earth
surface. The numerical propagator failed for this object, throwing
an exception as the adaptive stepsize numerical propagator required a
step size lower than allowed minimum.

The generated output was about 2.3 gigabytes. It took 269 seconds to
generate all trajectories on a four years old laptop with a core-i5
processor, 8Gb ram, running Linux Debian stretch.

best regards,
Luc