[Orekit Developers] progress report on thread safety

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Hi all,

Here is another progress report concerning one of the major Orekit  
issues now: thread safety.

Yesterday, a big step forward has been done with commit b27c9ead (see  
<https://www.orekit.org/forge/projects/orekit/repository/revisions/b27c9ead555f327e14a7f01e2a1d4fdc8ea22637>).

The core of this change was to remove the various caches spread  
amongst the frames classes and to use the new  
InterpolatingTransformProvider instead.

The responsibilities of the new classes are the following one:

 - CIRFProvider, ITRFProvider, MODProvider, TODProvider and all similar
   classes are the core computation engines for reference transforms
   (precession, nutation, sidereal time, pole motion ...), they only
   compute one transform at a time and don't care about cache or thread
   safety

 - TimeStampedCache is a general purpose cache for things that are time
   related, its main purpose is to provide in a thread safe manner a
   small local array of entries which surround a given date

 - InterpolatedTransformProvider combine one core transform computation
   engine and one time stamped cache to add several features to the
   core engine:
       * reduce computing cost by using interpolation instead of
         always doing the full computation
       * reduce computing cost by caching already done core computation
       * add thread safety

 - FactoryManagedFrame is a general frame implementation for predefined
   frames that uses a transform provider (either a core one or an
   interpolated one)

 - FramesFactory is the user level interface for creating predefined
   frames

The various providers and the TimeStampedCache are mainly internal  
classes (but users can of course use them to create their own frames  
using a similar architecture). They are new classes, but most users  
can simply ignore them. FactoryManagedFrame was slightly changed (to  
use a TransformProvider), but its purpose with the new thread-safe  
architecture is similar to what it was before the change.  
FramesFactory has been adapted to use the new architecture but its  
public API ant its behaviour have been preserved so users do not need  
to do any change in their code. Thread safety is almost transparent  
for them!

All the thread-safe caches are configured using the  
OrekitConfiguration.getCacheSlotsNumber() method to set up the number  
of independent slots used in the cache. This number is related to the  
number of concurrent threads that are expected to be used. If users  
did not do any custom configuration, this number is set to 100 which  
should be sufficient for most uses. If very few threads are really  
used and if simulation time evolves continuously, the extra slots will  
simply hold null pointers, so no memory is really wasted with this  
large number. If several threads are used or if simulation time jumps  
randomly to dates which are far away from each other, then new slots  
will be created as needed and more memory will be used. So in such  
cases, users should configure the numbers of slots in cache according  
to their needs.

Note that the interpolation feature does compute angular velocity even  
if the underlying core transform provider does not compute it (it is a  
by-product of the polynomial model). This implies that now frames like  
TOD or CIRF *do* include the very small precession/nutation velocity  
composition effects. This is an improvement for the library but it  
does change some numerical results (it is of the order of magnitude of  
1.0e-5 to 1.0e-4 m/s in LEO, higher in GEO). We had to adjust some  
frames unit test thresholds as the reference results did not take this  
effect into account. So users may expect some tiny velocity changes in  
their own test cases. Please report if you think there is an error  
there.


The only caches that seem to remain now (unless I forgot some) are in  
the DTM2000 and Ephemeris classes.

The first one correspond to various intermediate data that are  
computed when getDensity is called, and reused when getTinf, getT,  
getMam and getPartialDensities methods are called. As there is  
specific scheduling of these methods to be fulfilled, it is not  
possible to use a class level synchronization. Of course, we may  
gather all these fields in one specific TimeStamped container and use  
a TimeStampedCache to hold them, but I am not sure this is worth the  
work. This class is intended to be used in force models for numerical  
propagation and propagators are not thread safe. Having complete  
thread-safe propagators seems unrealistic. What are the other  
developers opinions about this ?

The other cache is in the Ephemeris class. It is very similar to  
already modified classes and a perfect fit for TimeStampedCache (it is  
simply a collection of Spacecraft and an interpolation). I am working  
on it. The change will indeed improve the class as it will rely on the  
new interpolation capabilities of SpacecraftState which can use more  
than two points and preserve the type of the orbit (the current  
ephemeris creates only equinoctial orbits). Once this class is  
changed, I think I will finally set the status of issue #3 to resolved!

best regards,
Luc


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.