RE: [Orekit Developers] Is serialization of propagators really useful

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

Tanguy Yannick <Yannick.Tanguy@cnes.fr> a écrit :

> > Hi all,
> Hi Luc,

Hi Yannick,

> > From the very beginning of Orekit (back in 2002), some basic  
> > priciples have been applied throughout the library. [..] Since this  
> > change, when a numerical propagator was serialized and  
> > deserialized, the new propagator had no integrator anymore. So the  
> > user was required to reset a new integrator using the new  
> > setIntegrator method. This was not really satisfying.
> >
> > We are now facing worse problems as there are more places were  
> > objects cannot really be serialized. As an example, force models  
> > may require a celestial body such as the Sun, which is provided as  
> > a PVCoordinatesProvider, which is not serializable. Even if the  
> > providers available in Orekit such as CelestialBody could be  
> > serialized, it would be a very bad idea to do so as they can have  
> > huge datasets.
>
> I agree that some objects don't need to be serialised.
>
> > There were several (heated) discussions about serialization a while  
> > ago in the Apache Commons Math (see  
> > <http://markmail.org/thread/26zmab5xo2rr4eap> for the last one).  
> > The outcome was that basically serialization must not be a general  
> > rule and should be done properly and one a case by case basis. One  
> > of the interesting outcome of these discussions is a trick that  
> > allows users of a non-serializable class to still use serialization  
> > in their top level class as they requires it using proxy objects to  
> > replace the non-serializable ones (the use can be because they have  
> > a non-serializable field in their class or the extend a  
> > non-serializable class). This is used in Apache Commons Math at a  
> > few places (see for example PointValuePair, which is a case where  
> > the serializable class extends a non-serializable one). We also  
> > have started using this trick in Orekit as well (see for example  
> > the DataTransferObject inner class in the  
> > InterpolatingTransformProvider class in the frames package).
> >
> > So our basic principle about serialization is difficult to manage,  
> > and thanks to the proxy objects trick it is in fact not really  
> > needed anymore. I would propose to follow Apache Commons Math  
> > policy and limit our use of Serializable to some basic classes  
> > where it makes sense (typically data containers like orbit,  
> > attitude, date, transforms, body shapes, geodetic point ...) and  
> > remove it for complex cases like Propagator or AttitudeProvider.
> > What do you think about this change?
>
> I agree with this principle, because serialisation may cause a lot  
> of difficulties for complex objects with some algorithm (propagator,  
> attitude provider, force models, event detectors,..). The use of  
> Serializable for only the small data containers seems a good idea.

I also think now that event detectors and step handlers should not be  
serializable. One difficult part is step interpolators, though,  
because they are used for ephemeris generation and ephemeris *should*  
remain serializable. We have to look at it carefully.

best regards,
Luc

> best regards,
>
> Yannick
>
> > best regards,
> > Luc



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