[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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