Next Orekit version

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

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.


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.


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.


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!


The merge request is created.


The new maneuver package reorganization is merged into develop branch. Hipparchus 1.7 is released. So, we are ready to release Orekit 10.2!

If it is ok for you, I’d like to start the release process this afternoon or tomorrow morning.

They are two points that have to be finished before starting the release process:

  • Merge !55 into develop branch. I will do that this afternoon.
  • @evan.ward do you want to fix #643 for 10.2 or we can reprogram it for the next release ?

Thank you,

1 Like

+1 for using current state as Orekit 10.2 version.

I’m not going to have time to fix #643 today, so it’s fine to move to the next release. It should be a fairly quick fix of just creating a new DecimalFormat each time it is used.

Thanks for doing the release!

+1 for me to release the current development branch, thank you.

@yzokras you did not defined a Copyright in your class header. I cannot merge the branch without it… Can you define or provide one? Thank you.

Thank you for your reply. I remove the milestone of #643.

Everything is merged into develop branch. I start the release process.