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 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
TBD (see issue #13, plus add already started work).
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