In July 2011, ESA launched its Summer Of Code In Space (SOCIS) initiative. The main SOCIS
site is located here: http://sophia.estec.esa.int/socis2011/.
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 a demonstration application with user interaction for Orekit features,
- create a web application for orbit propagation with operational forecasts
- create a 3D vizualization application for attitude
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 work packages:
* 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: http://public.ccsds.org/publications/archive/502x0b2.pdf.
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 work packages:
* 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 ...),
Up to 5.x series, the Orekit library supports only JPL DE404 and DE405 ephemerides. JPL has published more accurate
solutions like DE414 or DE421 (see http://ssd.jpl.nasa.gov/?planet_eph_export), which are based on very similar binary file
format. At the same time, IMCCE has published its own solutions for planetary ephemerides like INPOP8 and INPOP10A
(see http://www.imcce.fr/inpop/), which also share similar file formats.
IMCCE also published a C library for file reading, the calceph library (see http://www.imcce.fr/inpop/calceph/index.php). As of
version 1.2.0, this library is now published under a triple licensing model, including CeCILL-B licence which is compatible with
Apache Software License V2, thus allowing us to translate it and include the translation in Orekit.
So Orekit should be improved and be able to read all these types of ephemerides, as requested in issue #23. This could be
done either by improving our current parsing classes which support DE404 and DE406 or use a translated version of calceph.
The current parsing also support only the Big Endian version of the file. This could be trivially extended to support both
Big Endian and Little Endian versions, and even detect automatically the byte ordering.
Another possible improvement could be to add the VSOP87 theory, which uses much smaller data sets (see
ftp://ftp.imcce.fr/pub/ephem/planets/vsop87/), and hence could be more suited for applications on small devices.
The work to be done will be split in four work packages:
* analyze the differences in file format for JPL DE files and IMCCE INPOP files,
* compare the existing parsing routines in Orekit and the calceph library, and select the more suitable one,
* implement reading of all JPL and IMCCE files,
* implement VSOP87 ephemerides.
h2. create a demonstration application with user interaction for Orekit features
Orekit is a low level library. As such, it does not provide any visible user interaction and does not display anything
fancy. It must be called by a top level application which configures its and provides it the initial data to propagate.
It is therefore difficult to explain Orekit features and have new users play with it a little to get a grasp of what
it can do.
The purpose of this subject is to set up a calling application that can be used as a showroom for Orekit features.
It is focused more on the input than on the output, i.e. it should be able to select features and run them quickly
in front of an audience. The application should have both a set of predefined configurations showing specific features
(orbit propagation, events, frames transformations, time scales, attitude ...) and allow user (even new ones) to change
the setting and see immediately the effects of the settings. For each feature, links to example code, tutorials and
documentation would be an interesting add-on.
The display part should not be the main concern, but it should still not be neglected. It should at least include some
simple form-based results (a propagated orbit, an event occurrence report ...), tabular outputs (orbits and attitude
ephemerides ...), curves and plots, and animated 2D views (satellite ground tracks, sensors footprints, ground station visibility circles
...). No 3D views are considered here (yet).
The work to be done will be split in nine work packages:
* select the features to be demonstrated,
* for each feature, find the most educational use cases to present it,
* identify the configuration parameters and set up reference scenarios,
* implement a top level application with graphical user interface to run these use cases with simple textual output,
* add tabular output for ephemerides,
* add 1D curves with some specific marks for discrete events,
* add 2D ground tracks,
* add sensors footprints and ground station visibility circles,
* add time animation and events triggering feedback
h2. create a web application for orbit propagation with operational forecasts
The purpose of this subject is to study the suitability of the Orekit library various propagation modes
in web applications.
Orekit provides several modes for orbit propagation (see https://www.orekit.org/static/architecture/propagation.html).
The more classical one is slave mode: the propagator is the slave and the calling application is the master. In this mode,
time evolution is entirely driven by the application and at each call the library computes one final state and returns it.
Another mode which is less intuitive but more powerful, more efficient and leads to simpler code is master mode: the
propagator is the master and the calling application is the slave. In this mode, time evolution is entirely driven by the
library and the application calls only once the library and let the propagator drive time evolution and call it back at each
step end, providing it a local interpolation model valid throughout the computed step. The last available mode is ephemeris
generation, where a first propagation is done by the library, then an ephemeris is generated and returned to the caller,
and afterwards the caller uses the ephemeris and navigate at will throughout its time range, possibly going back and
All these modes change the interaction schedule between the caller and the library. Handling all these modes is well
understood for a standalone application with direct method calls. We would like to know how these modes scale in
distributed environments, with a server performing the computations and a remote lightweight client connecting
to it. A typical use case would be a tiny device (say a mobile phone) with limited computed capacity and no storage
of large data requesting a computation of operational forecasts with full-blown accuracy and complete models to
a server from the operational ground system.
The objective of this subject is to implement this use case using the three difference propagation modes and compare them.
The work to be done will be split in six work packages:
* design a Service Oriented Architecture for the use case,
* select and set up the framework (middleware, server, client), using a standard desktop computer for the client at first,
* design a communication architecture for each propagation mode (slave, master, ephemeris generation),
* implement all three architectures,
* analyze and document ease of design and implementation for all architectures,
* analyze performances for all architectures.
h2. create a 3D vizualization application for attitude