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