I created this topic in order to collect your opinion about the next version of Orekit (minor or major version, final program, etc.). Before giving your opinion, please find the current status below.
Already developed features:
Trajectories around Lagrangian point using CR3BP model.
Looking at the program, I think we have an amazing program to do the next release soon. The main advantage of the developed feature is that there is no API changes. Therefore, next version can be a minor version.
The advantage of doing the next release soon is that we can start the development of the next major release soon. This allow to start the development of the multi-module architecture just after the next release (i.e. beginning of June).
That is why I think we can release the next version of Orekit (i.e. 10.2) for the end of May. Final program can be exactly the previous points with some other issues fixed (for instance #674, #667, #662, #651). If you want to fix other issues for 10.2 release do not hesitate to add them to the list.
This is just my opinion. Your opinion is important.
Kind regards,
Bryan
I agree with the program.
I wonder if we should also attempt to get an Hipparchus 1.7 release and switch Orekit dependency
to this new released version. It includes several bug fixes (and seems to introduce new bugs as I
have seen today, working on it…)
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. Thanks for getting this process started!
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 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.
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 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) ?
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.
#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.
Thanks for getting this process started!
