SOCIS » History » Version 4

« Previous - Version 4/41 (diff) - Next » - Current version
Luc Maisonobe, 2011-07-08 11:36


In July 2011, ESA launched its Summer Of Code In Space (SOCIS) initiative. The main SOCIS
site is located here:

The Orekit project proposes the following subjects to the students. Note that until the mentor application date
is over (2011-07-15) this list will be completed and updated, so if you are interested you can always
come back to see new proposals. Also if anyone has new subject ideas, do not hesitate to discuss
about it on the development mailing lists.

  • secure multi-threading in Orekit while preserving data caching features
  • implement support for CCSDS Orbit Data Messages
  • add support for more planetary ephemerides models (DE414, DE421, INPOP08, INPOP10A ...),
  • create an animated 2D view application of satellite tracks with sensors footprints
  • create a web application for orbit propagation with operational forecasts

h2. secure multi-threading in Orekit while preserving data caching features

One important issue with Orekit is issue #3: Orekit is not thread safe. Thread safety implies making sure
concurrent code block are properly synchronized for shared data access. However, a simple approach like
putting synchronized keywords does not work with Orekit.

The reason it does not work is due to the fact some shared data is used for caching purposes. Typical examples
are Sun and Moon ephemerides from JPL files and precession/nutation models for Earth frame. In both cases,
when user code requires a position or an orientation, it calls a method with a date. This date is used to read
(in the first case) or compute (in the second case) a polynomial model valid at the required date, and to apply this
model for the specified date. Often in space flight dynamics applications, computations are organized around main
loops in time, so a request at date t0 will be followed by a request at date t0+h1, than another request at t0+h1+h2
with small time steps h1, h2 ... As reading or building the polynomials models is time consuming, these models are
cached in memory and reread/rebuilt only when a request is done for a date outside of the validity domain of the
current model in cache. Most of the time, huge savings result from this architecture: when a model is build, it will
be used for a huge number of calls. As an example, the precession/nutation models are valid for 12h time ranges, so
a computation using a fixed time step of one minute will need to rebuild the polynomial model only once every 720 calls!

This reasoning does not hold anymore for multi-threaded applications. Consider for example a distributed application with
a central computation server and several unrelated client applications. One application may be performing orbit
determination from previous week measurement data while another application may be preparing observation planning
for next week. If both applications hit the server at alternate times, each new request for Earth orientation from one
application will find the current model cached by the other application is too far away in the past or in the future, then it
will invalidate the cache, recompute the model, apply it and leave it in cache where the next application will find it, consider
it to far away in the future/past, invalidate it, recompute ... The net result will be that instead of improving performances,
the cache will drastically decrease performances.

What we need for Orekit is a way to have both thread safety (with synchronized block and shared data), and keep
data caching features, and be able to handle cache efficiently even in multi-threaded mode. In distributed environments,
we cannot even suppose one thread will always serve requests for the same client, so we cannot even associate a cache
with a thread. We have to associate cache with time ranges, which may be overlapping.

The work to be done will be split in four parts:
* identify the main thread safety problems in Orekit (the first known examples are frames transforms and celestial body ephemerides),
* identify the data caching needs,
* propose a technical solution to address both problems at the same time,
* implement and test the proposed solution.

h2. implement support for CCSDS Orbit Data Messages

The Consultative Committee for Space Data System is an international standardization body dedicated to space.
It has published numerous recommendations which are mandatory in many space systems development and improve
interoperability. One of these recommendations is the Orbit Data Message. Version 2 of this document has been published
in late 2009 and is available here:
Orekit should support this recommendation, as required in issue #13. plus add already started work).

The recommendation defines three different messages for different needs:
* Orbit Parameter Message (OPM),
* Orbit Mean-Element Message (OMM),
* Orbit Ephemeris Message (OEM).

All messages share roughly similar text-based structure which are fairly easy to parse. There are however many
pitfalls. Some values may be adapted for mission-specific needs and handling them on a general-purpose library
requires providing some hooks for user code. Some definitions are not really complete like which frames can be
frozen at some epoch and which cannot. Some definitions are also redundant (frames names ...).

The mapping between CCSDS Orbit Data Messages and Orekit object model is not direct. Some elements are split
in different ways and requires some care to be transformed properly.

One particularly important difference is the fact Cartesian orbits in Orekit do require a gravity coefficient which
may not be present in the data. This is a problem in Orekit which must be solved, so the Orit hierarchy must be
adapted, either by moving the CartesianOrbit at a different level in the inheritance hierarchy or by having two
different classes, a base one without gravity coefficient and an extended one with the gravity coefficient. As
switching between any orbits type should remain possible and orbits are used throughout the library, the
inheritance design must be carefully crafted and its consequences on the rest of the library and existing user
code must be evaluated. Another issue also related to orbit representation and acceleration has been registered on
the issue tracker as issue #22, it may be interesting to look at it at the same time.

The three messages types are quite independent from each other, but will most probably share a common parsing
infrastructure. Some work has already been started on this and will be provided to the student at the beginning.

The work to be done will be split in seven parts:
* identify the needs for cartesian orbits with and without gravity coefficient,
* design an updated orbits inheritance hierarchy,
* implement the new hierarchy,
* design and implement a common parsing infrastructure for all messages types
* implement Orbit Parameter Message (OPM),
* implement Orbit Mean-Element Message (OMM),
* implement Orbit Ephemeris Message (OEM).

As this work is large, we are considering splitting it in two different subjects, one for the orbits hierarchy and
another one for Orbit Data Messages. In this case, the projects will be independent, i.e. reading OPM with Cartesian
parameters but without gravity coefficient in the second subject will not be supported at first, and support will
be added by the Orekit team once both subjects are completed and integrated together.

h2. add support for more planetary ephemerides models (DE414, DE421, INPOP08, INPOP10A ...),

TBD (see issue #23).

h2. create an animated 2D view application of satellite tracks with sensors footprints


h2. create a web application for orbit propagation with operational forecasts