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

[paulcefo@buffalo.edu]

Hello Luc,

Paul

Dr. Paul J. Cefola
Adjunct Faculty, Mechanical and Aerospace Engineering, University at Buffalo (SUNY)
Consultant in Aerospace Systems, Spaceflight Mechanics, and Astrodynamics

paulcefo@buffalo.edu
paul.cefola@gmail.com

508-696-1884 (home phone in Vineyard Haven, Massachusetts)
978-201-1393 (cell)

On Mon 06/11/12  6:37 AM , MAISONOBE Luc luc.maisonobe@c-s.fr sent:
> 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
> transformsare valid only at a specific date, and only a few of them are
> independentof 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
> tohold 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
> recomputingevery individual transform throughout the frames tree (this is used for
> example to implement the shift method in the Attitude class, so the
> codewhich 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
> haveto 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
> infact 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
> isreally a problem, as Transforms are often transient objects which are
> notused 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.
> 
> 
> 
> 
> 
>