Orekit 9.3 is out, what's next?

Orekit development
#1

Hi all,

As Orekit 9.3 is finally out, we can think about the next development cycle.

A lot of things have been done in the last years that could not be included into 9.3 due to incompatible changes, we had to wait for a major release to include them. I think it is now due time to do a major release, which would be 10.0. I also think it would be nice to have it published really fast, before the Orekit day which is scheduled for May 23rd (save the date!).

The changes currently pending are:

  • propagation in non-inertial frames, without any central body
    (i.e mainly trajectories about Lagrange points)
  • DSST orbit determination
  • specialized propagators for all GNSS constellations
  • some API changes in models (magnetic field, tropospheric models)
  • changes with the events added by Evan and that requires also publishing a new version of Hipparchus

Other changes I would like to add are:

  • a working phase measurement class with ambiguity resolution
    (the current one is only a non-working stub)
  • combined measurements (for example iono-free)
  • improving API for ionospheric models

Some other points that may be worth adding in 10.0 or could wait a future version are:

  • a feature to automatically feed atmospheric models with solar activity
  • one line elements sets

What do you think about this?

#2

I realized that my first message assumes that next version will be 10.0, but this should
also be taken as suggestion only.

The preliminary question should therefore be: do you think next release should be a major release or a minor release?

#3

Hi,

For the first question, I think that next release should be a major release because many of the projected changes will cause incompatibilities and it is interesting to add them into Orekit, especially because some of these changes are well advanced in development.

For the second question, add the three first changes (ambiguity resolution, combined measurements and the new API for ionospheric models) to the changes currently pending can be sufficient to have an interesting 10.0 release.

Bryan

#4

That’s a nice list of new features. I would like to include #389 which is a change to generic declarations to improve usability.

#5

Yes, adding #389 would be nice.

I also think I forgot another major point: redesigning the data providers. There were some discussions in November 2017 on the old lists. Messages appeared on both the users list (see https://www.orekit.org/mailing-list-archives/orekit-users/msg00192.html) and on the developers mailing list (see https://www.orekit.org/mailing-list-archives/orekit-developers/msg00084.html).

#6

If we want to release 10.0 by May 23 I think we need to have a RC by May 15. That is 5 days to finish the remaining issues. Here are the remaining issues I see:

I think we can postpone redesigning the data providers until the next release. Any other issues we should include?

Who is going to be the release manager?

#7

Hi @evan.ward,

On my side, other issues that shall be finished for the 10.0 are:

  • #522 #521 #520 and #519

  • API change for new ionospheric models. Their development can also be added to the 10.0.

  • Integration of the DSST Orbit Determination

All this jobs a more or less finished. They are waiting for some final validations. However, I think that the 23 of May is a little bit too early for me if I want to finish the job correctly. Moreover, OrekitDay is fast approaching and we have to finish its preparation. In that respect, I think that it is better to postpone the deadline in order to do the release properly. Rather than releasing a wobbly version. What do you think ?

Bryan

#8

Those will be some nice new features. I think taking the time to get a solid release is smart. When do you think you’ll have it ready?

#9

It depends on the time I take to find a bug on one of the new ionospheric model that I am implementing :grinning: After finding this bug the new ionospheric models will be ready to be merged. After that I need one or two days to check that everything is ok for the DSST OD and approximately one or two other days for the GNSS propagation (JavaDoc, …).

#10

Hi everyone,

I just resolved #514 and updated Hipparchus dependency to version 1.5 (see #546).

Note that we’ll also have to merge the branch propagation-in-non-inertial-frame in develop branch for version 10.0.

For the rest I agree with you both that the release should be solid before it is aired.

Maxime

#11

Hi,

I have pushed my ongoing work on integer ambiguity resolution for GNSS phase measurements.
It is far from complete now but at least is a starting point that could be completed after 10.0 without introducing further incompatibilities.

We should also not forget to ask the translators to update the error messages translation files. They usually need a few days to review the new messages and send the files back.

#12

Thank you @luc !!

#13

Hi,

No #518 has a PR at https://gitlab.orekit.org/orekit/orekit/merge_requests/8

It is just a change from public to not public.

Regards
/Petrus

#14

Hi,

I just merged branch propagation-in-non-inertial-frame into develop (see #554).

I removed 2 tutorials: EarthMoonL1Trajectory and EarthMoonL2Trajectory because they are not ready yet.
They are still available in branch propagation-in-non-inertial-frame though.

I added the tutorial PropagationInNonInertialFrame, written by Laurene Beauvalet.

Regards,
Maxime

#15

Hi,

Issues #519 #520 #521 and #522 are fixed.

Package reorganization has been performed for the models package.

DSST Orbit Determination is now in develop branch :tada:

Now, I just have to finish the new API for ionospheric models.

Regards,
Bryan

#16

Hi,

Issues #529 #551 #552 and #553 are fixed.

I added an EventDetector based on magnetic field intensity in the develop branch.

Regards,
Romaric

#17

Looks like the only issue left for 10.0 is #547, which Luc is working on. Anything else folks are working on that is going into 10.0?

#18

I hope to fix #547 today or Monday. We discussed about it with Pascal yesterday and he found a very clever way that I am going to implement.

#19

Hi Evan,
Besides the current work of Luc on issue #547, we just polish up the code, fixing or updating javadoc and documentation for the maven site. We are about to finish this tedious work.
What about issue #561 ?

#20

I think #561 is rare enough that it would probably never be hit unless someone went looking for leap second bugs. :wink: I’ll work on it some the next couple days, but I don’t want to hold up the release for it.