[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Tanguy Yannick <Yannick.Tanguy@cnes.fr> a écrit :


Hello,


Hi Yannick,
Here is a summary of what we did recently, trying to use the TimeStampedCache to solve some of our issues. First we tried to solve the problem of data corruption, and then, time calculation by using TimeStampedCache instances.
We introduced a small change in the getTransformTo method from the Frame class, adding synchronized blocks, as shown below : 

        // transform from common to instance
        Transform commonToInstance = Transform.IDENTITY;
        for (Frame frame = this; frame != common; frame = frame.parent) {
            synchronized (frame) {
                frame.updateFrame(date);
                commonToInstance =
                    new Transform(frame.transform, commonToInstance);
            }
        }

        // transform from destination up to common
        Transform commonToDestination = Transform.IDENTITY;
for (Frame frame = destination; frame != common; frame = frame.parent) { 
            synchronized (frame) {
                frame.updateFrame(date);
                commonToDestination =
                    new Transform(frame.transform, commonToDestination);
            }
        }
These changes were made for some of our multithreaded use cases that performed better in this case. But two propagations running each on one thread performed badly (extremely slow). Through profiling we found the cause of the slowdown to be constant cache swaps in the CIRF2000Frame class.
Yes, this is exactly what we have been saying for about two years now (see our proposal to one of your RFP long ago, see the discussion on bug 3 at <https://www.orekit.org/forge/issues/3>, see the first proposal for SOCIS 2011 at <https://www.orekit.org/forge/projects/orekit/wiki/SOCIS>, see various private discussion ...).
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 ?
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 test we made is to use several threads that run frame computations on different time spans. Each thread calculates PV coordinates in ITRF from an initial orbit in GCRF (an orbit every hour during one month). Then we compare frame computations in non-parallel and parallel threads, called ThreadOrbitShift. This program shows in a "vanilla" Orekit that parallel computations are very slow and (on close inspection of the files written to TEMP) produce corrupted data. 

This is the problem TimeStampCache attempts to solve.
But then, changing getTransformTo as shown above solves the data corruption issue; replacing CIRF2000Frame by TimeStampedCIRF2000Frame (in FramesFactory.getCIRF2000() ) solves the performance issue for parallel computations. For example, two threads launched one after the other take 8 s to calculate the coordinates. The initial OREKIT implementation could take up to 4 minutes with parallel threads and give wrong results. With the new implementation, a parallel calculation take a bit more than 4s and give exactly the same results. 

Great! Thanks for the report.
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.
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. 



Best regards,


best regards,
Luc



Yannick TANGUY, Pierre CARDOSO






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