RE: [Orekit Developers] IERS 2010 & frames configuration

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

[...]
>>>> 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. 

>Mixing frames is not only used for study purposes, a more classical way any user can need is when exchanging data between different legacy ground systems. If your own system uses IERS 2010 and you need to send data to a system that uses IERS 2003 or even IERS 1996, you must be able to use all these frames at the same time in your application and to convert between them!
>Also how do you intend handle distributed applications when one user uses a convention and another user uses another convention? Here again, the server side part must be able to handle both conventions at the same time.

Ok, your first example is quite realistic and must be covered. We'll work on the design and will propose an other solution.
 
>>>> 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.

>I don't agree with suppressing these frames. They are needed and as per the examples above, they may be needed at the same time in the same application.

>> 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.

>Fine, thanks.

>>>> 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.).

>OK, I'll wait for this to be available.

>best regards,
>Luc

> 
> 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
>>>
>