Next Orekit version

I agree with this assessment as well.

I think releasing in May or early June is a good idea. When do you want all the code changes finalized? I did a scrub of the issues I’ve reported and those related to time. I’ll try to do those assigned to 10.2. Help always welcome. :slight_smile: Thanks for getting this process started!

Thank you all for the answers.

It would be great if we can switch to Hipparchus 1.7.

It would be great if they can be finalized for the end of May. Something between the 27th and the 29th of May. In this way, release process can start the first week of June. But there’s no hurry.
I also have some issues to fix for the release (i.e. #674, #667, #662, #651 and maybe some others).

I agree with everyone: a new version of Orekit is always welcome. Release early, release often !

2 Likes

My favorite mantra! :slight_smile:

1 Like

I have added UnivariateDerivative1, UnivariateDerivative2, Gradient, FieldUnivariateDerivative1, FieldUnivariateDerivative2 and FieldGradient to Hipparchus, thus solving issue 93.

I hope this could improve Orekit performance in a number of places, mainly in the orbit determination. I cannot check this before I come back. Could someone give it a try? The idea would be to first do a simple search for calls to DSFactory and FDSFactory constructors to see when they are called with either order =1 or order = 2. In fact, I guess most of our uses in Orekit are with order = 1, so there are several places where this could be used. If I remember well, in real applications we spend a lot of time in the various DerivativeStructure methods, so I hope there will be a gain.

It is possible to convert back and forth between these new classes and regular DerivativeStructure, but I fear it could hinder performances, so if we switch in some places to the new classes, we should stick with them.

Let me know if you need more adjustments, and if someone gives the new classes a try, let me know if it improves things or not.

1 Like

I’m so curious to see if it can improve OD performance! I will perform the change. However, I will have to see how these new classes work before.

For orbit determination (i.e. DSConverter and measurement evaluation), order = 1 is used. order = 2 is used for analytical propagators and for GNSS attitude providers.

Using the new classes, the following code:

    // prepare derivation variables, position, optionally velocity
    final DSFactory factory = new DSFactory(freeStateParameters, 1);

    // position always has derivatives
    final Vector3D pos = state.getPVCoordinates().getPosition();
    final FieldVector3D<DerivativeStructure> posDS = new FieldVector3D<>(factory.variable(0, pos.getX()),
                                                                         factory.variable(1, pos.getY()),
                                                                         factory.variable(2, pos.getZ()));

can be replaced by:

    // position always has derivatives
    final Vector3D pos = state.getPVCoordinates().getPosition();
    final Vector3D vel = state.getPVCoordinates().getVelocity();
    final FieldVector3D<UnivariateDerivative1> posDS = new FieldVector3D<>(new UnivariateDerivative1(pos.getX(), vel.getX()),
                                                                           new UnivariateDerivative1(pos.getY(), vel.getY()),
                                                                           new UnivariateDerivative1(pos.getZ(), vel.getZ()));

Am I right ? (Is just to verify I good understood)

No, it is the other way round. If the initial code is new DSFactory(freeStateParameters, 1); it means you have three different derivation parameters and you differentiate to order one. Here we compute df/dx, df/fy and df/dz. So we should use Gradient in this case. With your proposal, you differentiate the position with respect to time, i.e. you compute dx/dt, dy/dt, dz/dt.

I think Gradient will be used almost everywhere, but there are probably a few places where we differentiate with respect to time, and in this case most probably up to order 2 when we compute accelerations (in PVCoordinates) or rotation accelerations (in Transform and Attitude). So I think more precisely that we will use Gradient and UnivariateDerivative2 and probably not UnivariateDerivative1.

I’m also eager to see the result you get :fearful:

three or six, depending on how freeStateParameters is set.

I think I didn’t understand how to use the new classes …

Do we have to replace all the DSFactory constructors or use them to initialize the Gradient objects (i.e. by using Gradient(DerivativeStructure) constructor) ?

I’m trying some implementations but I don’t want to generalize the use of the new classes without be sure at 100% that I’m on the good way.

Can you provide a small example on how to use Gradient class in Orekit? For instance on the code on my previous comment (extracted from DSConverter class) ?

Thank you

I think it would be better to replace them and avoid DerivativeStructure when we can.

I’ll provide a skeleton exemple.

1 Like

I have completed the exercise for the Range measurement. You will find it in my own repository in the branch hipparchus-gradient https://gitlab.orekit.org/luc/orekit/-/tree/hipparchus-gradient.

Beware that at the end of the theoreticalEvaluation method, when you go back from the Hipparchus derivative object (which was DerivativeStructure and is now Gradient in this example), and populate the Orekit jacobian matrices, you have to slightly change the indices. The reason is that in a DerivativeStructure, the value is at index 0 and the derivatives follow at indices 1 and more whereas in Gradient there is a separate getter for value and hence the getter for gradient starts at zero, not one. See how the indices were updated for the calls to estimated.setStateDerivatives and estimated.setParameterDerivatives.

Also note that in this class, the older DerivativeStructure and newer Gradient are built at the beginning of the method, used for computation, unpacked at the end and they disappear: their lifetime is limited to the scope of the method (and the methods it calls). A practical consequence is that the changes can be performed one class after the other. I was able to do it for Range only, without touching other measurements. Of course, I also had to changes the classes called by Range, like AbstractMeasurement, EstimatedEarthFrameProvider, GroundStation and ParameterDriver. Fortunately, the changes for these other classes could be reused when converting other measurements classes. So for converting other measurements, the work should be easier than what I did for Range.

I did not look at the uses of DSFactory in the force models (DragForce, TimeSpanDragForce and ThirdBodyAttractionEpoch), files (AEMAttitudeType), propagation (DSConverter and DSSTDSConverter) but I think similar changes could be made.

The other uses of DSFactory are for univariate derivatives (for example in all orbits types and in PVCoordinates), so the UnivariateDerivative# classes would be better suited.

Thank you for provided an example. The use of Gradient is now clarified for me. I will try to perform the change for the other classes. I will probably create a merge request assigned to you in order to verify if everything is ok.

I have some orbit determination reference results (10k, 100k, and 200k measurements). I will use them to see if the new functionalities improves the performance.

@luc

I created a new topic to talk about the change: New Hipparchus functionalities in Orekit.
I performed the change for measurement classes and for the different DS converters. I made some conclusions on the OD performance.

Bryan

Hi all,

I’m doing small survey to be sure we are on the right track for releasing soon.

Concerning the issues still open (with a 10.2 milestone):

  • #684 I think this one can be close ? @evan.ward
  • #643 #638 #475 #448 Do you think we have to fix that issues for 10.2 or we can reprogram them for the next release? I propose to reprogram them.
  • #648 This issue is related to the maneuver package reorganization developed by @MaximeJ. It also include the contribution of @Mikael for low thrust maneuvers. If think we are very close to include this work in Orekit. What do you think?
  • #656 There is a merge request opened for that issue Is it ready to be included in the 10.2 program? @yzokras

There is also a small point that I have to finish. It concerns the new functionalities developed in Hipparchus (See New Hipparchus Functionalities in Orekit). I need about half a day to finish the development and include it in Orekit. I will do that Monday morning probably.

Bryan

About #656: we had several iterations with @evan.ward. There might still be a few minor things to change, in particular it would be good if someone can check whether my latest implementation achieved thread-safety. Otherwise I think the merge request is nearly ready.

About #648, that is good for me.

Unfortunately, the vote for releasing 1.7 version of Hipparchus failed as quorum was not reached.

Thank you all for your feedback,

Can you create a merge request on branch maneuver-package? Once the merge request accepted, I will merge it into develop branch.

It’s not a problem, we can wait until the Hipparchus version 1.7 vote. Especially since some new features are very useful in Orekit 10.2.

That point is now finished. It took longer than I expected. I created a merge request for develop branch. @luc, as you developed the Hipparchus part, can you have a quick look on this please?

Thank you again.
We are very close to release soon!

Bryan