[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Orekit Developers] ESA space debris movie - Orekit under the hood
For your information, the movie is also available in 3D stereoscopic vision (you need classical 3D glasses to view it).
This version is also quite impressive.
The link: https://plus.google.com/+EuropeanSpaceAgency/posts/W3a5sDRtPRS
Best regards
Nicolas
________________________________________
De : orekit-developers-request@orekit.org [orekit-developers-request@orekit.org] de la part de MAISONOBE Luc [luc.maisonobe@c-s.fr]
Envoyé : vendredi 28 avril 2017 14:51
À : orekit-developers@orekit.org
Objet : 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