[Orekit Developers] Shouldn't Transform implement TimeStamped and TimeShiftable

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Hi all,

I am currently working on the multi-threading issues, focusing on  
Frames as a first step forward. As I wanted to use the new  
TimeStampedCache to hold transforms between a frame and its parent  
frame, I considered changing Transform to directly implement  
TimeStamped. Of course, there are pros and cons about this change.

The pros are:

 - from a purely flight dynamics point of view, it does make sense.
   Transforms are specifically used to glue frames with each other,
   either directly for a frame with respect to its parent frame or
   indirectly by building a combined transform for converting coordinates
   between two frames which are not direct parent. Most of these transforms
   are valid only at a specific date, and only a few of them are independent
   of date.

 - whenever we use a transform, we either already have a date available
   or the transform is date independent, so it is really easy to link the
   transform with the date. I did it, and it took me less than one hour to
   propagate it throughtout the library, despite there are many many use
   of transforms (eclipse found 340 references to Transform)

 - I suppose this would simplify some user code, as for now users need to
   hold the date and the transform together by themselves, typically by
   having two parameters to any function that needs a transform, just to
   know the associated date

 - of course, if Transform implements TimeStamped, it is much simpler to
   use it with TimeStampedCache (otherwise, we would need to add an
   intermediate class to pack the date and the transform together)

 - if Transform implements TimeStamped, it would be easy to have it also
   implement TimeShiftable and have a new possibility to compute simply
   and very fast small time shifts in frames transforms without recomputing
   every individual transform throughout the frames tree (this is used for
   example to implement the shift method in the Attitude class, so the code
   which exist in the Attitude class could be moved to the Transform class)

The cons are:

 - It is a backward incompatible change (so if we want to do this, we have
   to do this now as 6.0 is a major release where incompatible changes are
   allowed, which will not be possible with later 6.1 minor release)

 - All Transform constructors must be changed to add the date (this is in
   fact quite simple, as it introduce compilation errors that IDE like
   Eclipse spot immediately so it is guaranteed no call will be missed)

 - The object holds one more field, so it is larger. I'm not sure this is
   really a problem, as Transforms are often transient objects which are not
   used or serialized in large numbers

I have made the change to check if everything was simple, and indeed  
it was. One unexpected change however was about combining two  
Transform instances to build a new one. The current constructor takes  
two arguments:

  public Transform(Transform first, final Transform second) {
    ...
  }

I have decided to add a date parameter also for this constructor, and  
to *ignore* the dates of the two raw transform. The rationale behind  
this choice was that sometimes we do combine transforms built at  
different times. A typical example is when doing some coordinates  
conversion involving one frame which is fixed with respect to its  
parent like EME2000 with respect to GCRF or a topocentric frame with  
respect to the body frame or some sensor frame with respect to the  
spacecraft body frame. The fixed transform is built as an arbitrary  
constant date (for example AbsoluteDate.J2000_EPOCH) and never  
changed. When this transform is combined with the next transform in  
the tree, the other transform depends on date and will not be  
AbsoluteDate.J2000_EPOCH. Another use case is when combining transform  
for interpolating, such computation involves combining the transform  
at date t + h with the inverse of the transform at date t to evaluate  
the evolution between the two dates. Both cases show combining  
transforms at different dates should be allowed without errors. It  
seems impossible to guess automatically which date to use. So I added  
the parameter and let the caller specify the date of the new  
transform, which may or may not be one of the underlying transforms  
date.

I have not committed the change yet. What do you think about it ?

Luc

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