[VOTE] Releasing Orekit 11.1 from release candidate 1

This is a VOTE in order to release version 11.1 of the Orekit library.
Version 11.1 is a minor release.

Highlights in the 11.1 release are:

  • Determination of maneuver start/stop time.
  • Brouwer-Lyddane model with Warren Phipps’ correction for the critical inclination of 63.4° and the perturbative acceleration due to atmospheric drag.
  • The Extended Semi-analytical Kalman Filter.
  • A new API for State Transition Matrix and Jacobian matrices computation allowing to link the computations directly to the orbit propagator.
  • Orbit determination using Eckstein-Hechler, Brouwer-Lyddane and Keplerian orbit propagators.
  • Parsing of ICGEM V2.0 format.
  • Several bug fixes in CCSDS files, TimeSpanMap, and display of dates.

The release candidate 11.1 can be found on the GitLab repository as
tag 11.1-RC1 in the release-11.1 branch:

The release notes can be read here:

Maven artifacts are available at

The votes will be tallied in 120 hours for now, on 2022-02-12T08:10:00Z
(this is UTC time).

+1 from me.
Checked a lot of things, found only old minor typos while reading doc again.

+1 from me thanks

+1 from me. I did a python wrapping this weekend and found no anomalies.

+1 from me thanks.

+1 from me


Nice work on the new features, especially the Brouwer-Lyddane implementation.

Question about the Duration and MedianDate classes. I would guess that duration is computed as d = t1-t0, but the class seems to implement d = 0.5 (t1-t0). Similarly I would think MedianDate would be implemented as tm = 0.5 (t1 + t0) but is seems to be implemented as tm = t1 + t0. Am I missing a factor of 1/2 or is the factor misplaced in the implementation?

Has there been any testing to show the performance improvements of using DoubleArrayDictionary? I would be surprised if there is a significant performance increase relative to HashMap or TreeMap, as there is no autoboxing avoided and Strings cache their hashcodes. But I am often surprised. :slight_smile:


This works the other way round. When using MedianDate and Duration, we consider that the independent variables are the median date and the duration and that start and stop dates are dependent variables. Then when one moves the median date say by one second in the future but keep the duration constant, this is equivalent to move both start and stop dates one second in the future. Moving a start date in the future means we remove a one second acceleration at start, and moving a stop date in the future means we add one second acceleration at stop, but the sign correction is already considered in the startTime and stopTime derivatives performed by other state providers, hence the computation. There is a similar trick for duration.

The expected improvements were mainly on memory rather than run time (default size for HashMap is 16 for example) because we generate a huge number of SpacecraftState, including intermediate ones when adding attitude, and then states/derivatives during propagation. Another point that was interesting (but was not the main design goal) is that the dedicated toString method that displays additional state name and size proved useful when debugging. I agree I should have done some performance tests, and also some memory consumption tests. I did not do that, I’m sorry.

I also did not check when I switched from triangular arrays in major row order to flat arrays in major column order backward from high order to low order in gravity fields (to match Holmes-Featherstone loops). Here again I should have done that, and here again performance gains are not expected to be really significant (except perhaps when high degree and order fields are used).

I am probably not demanding enough with myself when developing :woozy_face:

Makes sense, that is a nice feature to have pretty printed arrays. It’s good to have new features instead of being stuck analyzing. :slight_smile:

Thanks for explaining about the Duration and MedianDate.

My +1 for release.

This vote PASSED, with +1 from Luc, Nicolas, Petrus, Sébastien, Hank, Evan, Maxime, Pascal, David, Gowtham, lirw1984, and myself.

I will finish the release process next Monday :slight_smile: