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

[Orekit Users] Upgrading to Orekit v9.0 : how to handle the Fields ?



Hello,

 

First, many thanks for the release of Orekit v9.0. There is obviously a tremendous amount of work behind it. Some of the new features look very appealing to us.

We are currently in the process of switching our existing code base to v9.0. Most of this process has been painless so far : the few modifications that we had to perform in order to solve compilation errors were very intuitive. Good job on maintaining compatibility despite significant improvements !

However, we have hit a difficulty with our custom AttitudeProviders. Since commit 73f7d313 they are expected to implement a method getAttitude() that works with Fields. We were not familiar with this Fields feature, but it seems extremely powerful. In order to benefit from the new features, we have to refactor our code, and that is fine. In particular, it seems that Fields are now required for orbit determination.

However, it seems that Fields have been implemented in Orekit v9.0 as a kind of add-on. They do not replace existing methods, probably to avoid breaking compatibility ? This means that the AttitudeProviders have to implement two getAttitude() methods, the regular one and the new Fields one. We have attempted to implement this without code duplication by implementing the Fields method, then rewriting the regular method as a kind of wrapper around the Fields method. We have failed so far. Looking at Orekit AttitudeProviders, it seems that code duplication could not be avoided there either.

If the two implementations of getAttitude() are completely separate, I am afraid that bugs could lead to different behaviors between "regular" propagation, and orbit determination. Those bugs would certainly be tricky to isolate.

 

Did we understand this evolution properly, or are we missing something here ?

Is there a long-term plan for a tighter integration of the Fields ? Maybe by replacing existing classes with Field-based ones ? Knowing this could allow us to plan our refactoring accordingly.

 

Thank you very much for your input.

 

Yannick

 

 

***************************************************************
Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Airbus Defence and Space et les sociétés Airbus Group declinent toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space and Airbus Group companies disclaim any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------------------
Airbus Defence and Space SAS (393 341 516 RCS Toulouse) - Capital: 29.821.072 EUR - Siege social: 31 rue des Cosmonautes, ZI du Palays, 31402 Toulouse cedex 4, France