RE: [Orekit Developers] IERS 2010 & frames configuration

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

>> Hi all,

>Hi Yannick,

>First of all, I'm sorry for the answer delay. I have been busy doing other things recently.

>> 
>> In this mail, I try to sum up some some work we made on the IERS 2010 
>> frames. We started this development with the previous conception (each 
>> Frame has its own Transform) and before merging it in the new 
>> conception (see 
>> https://www.orekit.org/wws/arc/orekit-developers/2012-07/msg00009.html
>> ), we would like to discuss some technical aspects. Eventually, we 
>> wish to contribute this to Orekit before OREKIT 6.0 is released, and 
>> we'd like to know if you'd agree with this conception.
>> 
>> ** Why do we developed IERS 2010 convention ? ** OREKIT does (or
>> did..) not implement every detail of the IERS convention : - UT1-UTC 
>> and pole motion were interpolated with a linear method (it's not the 
>> case now) - the libration correction was not taken into account ; it 
>> affects UT1-UTC and pole coordinates (U,V) - the dX & dY angles are 
>> not corrected thanks to nutation
>> 
>> ->> So we had some difficulties to validate OREKIT frames
>> transformation in regard of our reference tools which implement IERS 
>> 2010. Furthermore, some users want to configure frames transformation 
>> very precisely.
>> 
>> ** Frames configuration **
>> 
>> The implementation we propose allows the user to configure each part 
>> of the terrestrial-celestial transformation (precession & nutation, s' 
>> correction, libration correction, tidal models) using a 
>> FramesConfiguration object as a Frame attribute.

>Is there a default configuration or should user always specify the corrections they want to apply ?

Yes, the default configuration will be compliant with the IERS 2010 convention.
- take into account the libration effect
- non constant rotation : it takes into account dX/dt, dY/dt, dS/dt terms.
- tidal effects on pole motion & UT1-UTC 
- nutation correction (dX, dY)
- 4th order Lagrange interpolator to interpolate various corrections
We validated frames transformation with our reference tools.

For the unitary test purpose, it will be possible to use a configuration that will reproduce "old" OREKIT frames configuration.

>> The main idea is
>> that the user can configure the whole frame tree, by applying 
>> different conventions.

>Is it possible to use several configurations at the same time and get the transform between them? One use case that come to my mind is when users want to assess the effect of some correction: they would build one frame with the correction applied and the same frame without the correction, then the transform between these two frames would be the effect they want to study.

At first we wanted to do so, but we changed our mind.. Our first solution was to mix different conventions in separated frame trees. But it was hard to implement, and to maintain a "clean" tree of frames.
Finally, we think that it's quite unusual (and dangerous..) to manipulate different frame conventions at the same time. But we also imagined your use case for some expert users who want to study a specific correction. To do so, they can sucessively use different frames configurations and compare immutable "PVCoordinates". We think it's less confusing than having various frames in a same tree or having different trees. 

>> The configuration contains three elements : - a polar motion model : 
>> it depends on S' correction, libration correction and the tidal 
>> corrections - a diurnal rotation model : it depends on libration 
>> correction and the tidal corrections. - a precession & nutation model 
>> : at the moment, the IERS 2003 precession & nutation is implemented

>I fear too flexible configuration could lead to user errors. We have already seen this with the good old MSLIB: people could mix effects almost arbitrarily (using one theory with the constants from another).
>The current frames designed has carefully tried to avoid asking people to become frames transformation experts to use the frames. They currently need to know only the frame name, not what theory is used underneath and not how the frames are related to each other.

I understand your point of view, and that's why we tried to simplify the frame tree : on the IERS branch, we only have 4 frames : a terrestrial frame (ITRF), an inertial (GCRF) and two intermediate frames (CIRF & TIRF). We also propose to simplify the FramesFactory by suppressing the getCIRF2000, getITRF2008 and so on.
So there will be only one frame tree, with four different frames (plus the other frames based on equinixial transformations - MOD, TEME, etc.). If an expert user wants to modifiy the transformations between IERS frames, he can create his own configuration, but once he calls the "setConfiguration" method, the whole frame tree will be modified.

>I would very much like to have this feature (frames accessible to
>non-specialists) still available. does you design support this?

Yes, because a user won't have to manipulate frames configuration, except if he wants to use a customize configuration (for instance, to ignore UT1-UTC). For a simple user, the use of frame will be as simple as today.

>> 
>> Each model correction respects a specific interface, so new models 
>> could be developed (for future conventions), or simplier models can 
>> also be developed ; for instance, there would be a NoLibration class 
>> to be compliant with old OREKIT transforms.
>> 
>> By default, each user will get frames compliant with the new IERS 2010 
>> convention. But if the user wants to modify the frames tree 
>> convention, he can either create a frames configuration or get a 
>> predefined configuration (thanks to a FramesConfigurationFactory).

>Could you explain this a little ore please?

The FramesConfigurationFactory could provide predefined configurations (ie : one compliant with older OREKIT frames transformation, ..) but we still have to work on this subject.
Once we integrated the latest changes, we could provide some code example (ex : how to set up a new configuration, etc.).

Best regards,

Yannick

>best regards,
>Luc

>> 
>> ** Integration in the new conception **
>> 
>> It works well in an older version of Orekit (few months ago) but we 
>> now have to adapt it to the new conception : we have yet to modify the 
>> various TransformProvider to use the different models (libration, 
>> precession & nutation effects, S' correction, tides correction) and 
>> the FramesFactory to use Frames Configuration.
>> 
>> If you want more information, we can eventually attach some class 
>> diagram to Jira.
>> 
>> Best regards,
>> 
>> Yannick
>>