Orekit 10.2 has been released the 15th of July 2020. Since the last release, a lot of bugs were fixed, and a lot of new features were developed, representing a total 41 issues tagged 10.3 in the Orekit issue tracker.
Fix of short period Jacobian calculation in DSST orbit determination
Fix Kalman issues
Fix CCSDS ADM issues
Relativistic clock correction for most of measurements
Piecewise model for empirical forces
One-way GNSS Range and Phase measurements
Support for Laser Ranging data (i.e. both CPF & CRD formats)
Lense-Thirring and De Sitter relativistic effects
Clock drift for RangeRate measurements
Support for AGI LeapSecond.dat files
New interfaces for attitude ephemeris files
Knocke model for Earth’s albedo and infrared
Possibility to use multiple handlers for one event detector
A lot of other issues fixed
Because we have developed a lot of new features since Orekit 10.2, it is time to think about the new Orekit release!
Are the previous features sufficient for a new release?
Do you have any feature under development to add in the program?
Best regards,
Bryan
My opinion:
There is a lot of new features and bug fixed (41!). Furthermore, there are all compatible for a minor release of Orekit. Therefore, I propose to perform a 10.3 release of Orekit for the end of the year. I think it must be the last release of the 10.Y family. After 10.3 release, we could start to work on the next major release: the 11.0.
I just want to add #740 in the program. I need one day to perform the development.
If there is no new major contribution to add in the program, we can start the release vote next week, probably next Monday.
No, it is just a matter of changing the pom yet.
This will prepare for future work on looking on the FastMath.sin/FastMath.cos vs. FastMath.sinCos and
the SinCos addition and subtraction later on. You can start this conversion pass too, but the pom is the priority.
I will change the pom and looking on the FastMath.sin/FastMath.cos vs. FastMath.sinCos. I quickly look at into Orekit and there is not a lot of places where FastMath.sin/FastMath.cos are called successively for the same angle. SinCos addition and subtraction can be done later (i.e. for the next version).
There are some in Eckstein-Hechler (and were addition could be useful). See around line 664 in EcksteinHechlerPropagator.java (and probably in the field version too).
There is a lot of places where the change FastMath.sin/FastMath.cos to FastMath.sinCos can be performed (TLE, GeodeticPoint to calculate Zenith/North/Up coordinates, models package, etc.). It’s not a funny task but I’m working on it.
All the changes were performed. I also try to use SinCos.sum(...) when it was possible.
I don’t know if there is an improvement on the calculation time. I think so. Following is the duration of the tests of the 5 previous run of the CI tool in develop branch: 20.44s ; 20.48s ; 26.12s ; 25.44s ; 24.29s. After the change, the duration is 19.31s.
I don’t know if it’s a stroke of luck or a real improvement. The positive point is that calculation time did not increased!
I think that everything is ready to start the release process. If you agree, I will start it tomorrow in order to have a vote starting Monday
for releasing