RE: [Orekit Developers] Implementation of a CIRF 2000 Frame using a time stamped cache

[Tanguy Yannick <Yannick.Tanguy@cnes.fr>]

>> So we prototyped a variant of the CIRF2000Frame class, called 
>> TimeStampedCIRF2000Frame. It replaces the cache arrays for pole 
>> coordinates with an instance of TimeStampedCache. The 
>> TimeStampedGenerator implementation and the class provided by the 
>> cache (PoleCoordinates) are inner classes for 
>> TimeStampedCIRF2000Frame.  The code is attached below.

>I don't see any attached code, could you provide it please ?

Sorry, I forgot to say that the code is attached to the bug #3 in JIRA (https://www.orekit.org/forge/issues/3)

>> We found this variant produces the same computational results as 
>> CIRF2000Frame, without apparent slowdown in a monothreaded 
>> environment. In a multithreaded environment, it performs reasonably 
>> well (i.e. two computations running in parallel take a combined time 
>> shorter than the same two running one after the other - but not by
>> much.)

>Thank you very much for your tests. This is exactly what we wanted to achieve with TimeStampedCache. We are happy to see it works well.

>Did you encounter any problem using this cache ? Does the public API suits the needs for the frame ? Is it simple enough to set up for regular users ?

The implementation is very simple for now. Maybe we should allow the user to configure the nb of slots and the duration. 


[...]

>> We propose to use this implementation instead of the initial CIRF2000. 
>> We are going to attach the source code of TimeStampedCIRF2000Frame and 
>> the use case to the JIRA ticket.

>> Can you have a look at this source code ?

>We will have a look when it is available.

>Depending on the way it is done, we could either implement it as is or change it. One question we have now is whether this feature should be added on a frame by frame basis or globally at the top level of the base Frame class.

We don't have yet an opinion about this : the TODFrame also uses a cache and could be improved with the TimeStampedCache, but for the other frames, we don't see threadsafety problems. 

>As CIRF is concerned, the cache can be limited to pole positions. On a more general scope, the transform itself could be cached. We think this could speed up some other computations too.

Maybe it will allow to optimize some transformations when the last date is cached. But a first step would be to run more complex use cases to see if that optimization is needed.

Best regards,

Yannick

>> Best regards,

>best regards,
>Luc