[Orekit Developers] IERS 2010 frames implementation

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

Hello,

Some times ago, we proposed some improvement about IERS frames configuration (see discussion thread : https://www.orekit.org/wws/arc/orekit-developers/2012-08/msg00000.html).
We had some difficulties to implement it and to adapt our code to the new OREKIT frames and tries different conceptions.

Here is a summary of some problems user can encounter with the actual conception and what we propose. The use-case come from different users.

(0) Problems with current architecture:
* Some options are already available (tidal effects, EOP corrections), for each new option we need to add new branches in the frame tree. If we have 6 options and 2 choices per option, the combination will be enormous (2^6 frames ...). In fact we can consider that GCRF, CIRF, TIRF and ITRF frame are unique, but we can choose the transformation between those frames.
* By definition, ITRF is equivalent to the TIRF frame at date J2000 (TT), with Xp = Yp = 0. If we implement this test with current architecture, the transformation between ITRF2008 and TIRF is not identity. Because ITRF2008 is a son of ITRF2005, and there is a transformation between those 2 frames.
* Station position: with current conception, we can define a station position in the ITRF2008(with tidal effect) and we can compute the station position in the ITRF2008(without tidal effect), we will obtain a different position, while station position should be se same in ITRF FRAME with or without tidal effect!

(1) FrameConfiguration
This new class contains 4 objects that configure the transformation between the inertial frame and the terrestrial frame : 
- a PrecessionNutation instance (ie : transformation between GCRF & CIRF)
- a DiurnalRotation instance (ie : transformation between CIRF & TIRF)
- a PolarMotion instance (ie : transformation between TIRF & ITRF)
- an EOP data set (EOP2000History) 

These configurations class use different models that contains computation code : 
- the PrecessionNutationEffect interface, and two implementations : IERS2003PrecessionNutation (based on IAU 2000) and IERS2010PrecessionNutation (based on IAU 2006)
- the LibrationCorrection interface, and two implementation : IERS2010LibrationCorrection and NoLibration (for those who want to bypass this effect)
- the SPrime interface, and two implementations : IERS2010SPCorrection and NoSP (for those who want to bypass this effect)
- the TidalCorrection interface, and two implementations : IERS2010TidalCorrection and NoTides (for those who want to bypass this effect)

A FrameConfigurationBuilder allows to build FrameConfiguration instances, allows user to manipulate coherent Frames configurations.

(2) Frames tree
We will use one single tree with simplified names.
We propose to simplify the actual Frame tree because what users must manipulate is a coherent tree of frames : 
- one inertial frame (GCRF) and a pseudo-inertial frame (CIRF)
- one intermediate terrestrial frame (TIRF) and a terrestrial frame (TIRF)
The names ITRFyyyy (2000, 2005, 2008 and so on) refer to an ITRS realization, and we propose to create a kind of toolbox to manipulate Helmert transformations. Theses transformations are only used in very specific usage.

(3) How to fix the configuration (preferred configuration)
The configuration can only be fixed once in the FramesFactory, before manipulating any frame.
If no convention is passed to the FramesFactory, the IERS 2010 convention will be chosen, with all options activated (tidal, sprime and libration correction).
-> So a user who does not know about frames will use a coherent tree of frames with the latest IERS convention.

(4) How to convert between different conventions ?
When some user manipulates different conventions, he has to choose what frame can be considered as invariant. For some applications, it can be an inertial frame (GCRF, EME2000) but in most cases, when measures are handled, the terrestrial frame (ITRF) is the reference. In such case, one user must manipulate transformations very carefully. For example, if we receive external data from another space agency, in a TIRF frame and associated EOP, and want to work in "our" TIRF frame, we have to : 
- convert from "external" TIRF to ITRF, using their EOP
- then, convert from ITRF to TIRF with our EOP 

To do so, we propose that user manipulates directly the Transform object. We also propose to add another method to Frame : 
getTransformTo(Frame2, Date, FrameConfiguration) -> in that case, the Transform object returned will take into account another convention.

(5) Some use cases with new architecture:
Goddard ephemeris: 
The Goddard provides us ephemeris in the TIRF frame and their own pole corrections (Goddard convention). We need to convert these ephemeris in the TIRF frame corresponding to our convention. In this use case we can considerate that ITRF frame is the same in both conventions.
* Step 1 : Ephemeris_TIRF_GoddardConv conversion into ITRF frame using FramesFactory.getTIRF().getTransformTo(FramesFactory.getITRF(), Date, GoddardConvention) method. We obtain Ephemeris_ITRF
* Step 2 : Ephemeris_ITRF conversion into TIRF in  our convention using FramesFactory.getITRF().getTransformTo(FramesFactory.getTIRF(), Date, OurConvention) or FramesFactory.getITRF().getTransformTo(FramesFactory.getTIRF(), Date) if "OurConvention" has been fixed as preferred configuration.

ATV ephemeris :
GCRF is the exchange frame for ATV project, but this GCRF frame pole corrections and UT1-UTC corrections are null.
If we need to compare orbits provided by ATV project and orbits computed using measures and using a convention where pole and UT1-UTC are corrected, we can considerate that ITRF frame is the same in both convention.
* Step 1 : ProjectEphemeris_GCRF_ATVConv conversion into ITRF frame, using ATV convention, we obtain ProjectEphemeris_ITRF
* Step 2 : ProjectEphemeris_ITRF conversion into GCRF frame in our convention, we obtain ComputedEphemeris_GCRF.
* Step 3 : ProjectEphemeris_GCRF and ComputedEphemeris_GCRF comparison.

(6) How to handle different conventions (multi-threaded environment) ?
One problem still relies when different threads will use frames with different frame configurations. We don't identify this use case as usual in our applications, but as OREKIT is a low level library, we can't assert that some users won't try to do it.
With our conception based on a simple tree (and a "preferred" convention), the first thread can choose a convention, and then the others will have to cope with that. Maybe a solution will be to use a new cache (TimeStampedCache) to store transformations made with another convention. 
Theses use-cases must be studied furthermore.

Maybe we should use the existing JIRA ticket (feature #90) to attach some code or some images showing how we propose to modify frames.

Best regards,


Yannick TANGUY, Bruno VIDAL