MultipleShooter - Issues and possible improvements

Hello community,

I recently run into some troubles using the MultipleShooter class, and I would like to ask your help as well as propose possible improvements.

Dynamical model: Earth’s central attraction + Sun/Moon third-body perturbation

Test cases:

  1. LEO orbit, patch points generated from a reference orbit in Keplerian dynamics, corrected in Earth + Sun/Moon N-body model. This case converges successfully
  2. Earth-Moon L2 Halo orbit, patch points generated with external software, corrected in Earth + Sun/Moon N-body model. This case does not converge. However, using another software it converges in 5 iterations and negligible run-time

I attach the code I developed. Switch between the two cases is done commenting/un-commenting lines 64-65.

Other points:

  1. the multiple shooter class requires a number of constraints equal to the number of free variables. This is not required by the implemented algorithm, and it should be sufficient to remove lines 198-200 in AbstractMultipleShooting class (the check nFree>nConstraints) to overcome the limitation.
  2. remove the “arcDuration” parameter and compute the integration times as differences between the dates of subsequent patch points. Allow for different integration times for different arcs.
  3. I am not sure why the list of EpochDerivativesEquations must be passed as input to the class constructor. Can’t be they deduced from the propagators’ dynamical model? (6.3 KB)
patch_points.txt (10.4 KB)

Hi Alberto,

Thank you for your message and your recommendations.
We unfortunately have some identified bugs in multiple shooting and CR3BP models …

Any help is welcome because we have a lot of things to do in order to have a fully working functionnality.

Best regards,

Thank you Bryan,

I worked a bit more on the issue, and implemented a basic multiple shooter that handles only continuity constraints but allows for different propagation duration between subsequent points. The implementation is avalaible here: src/main/java/org/orekit/propagation/integration/ · multiple_shooting · Alberto Fossà / Orekit · GitLab
There are also two tests that validate the implementation w.r.t. a third-party reference.

I also managed to make MultipleShooter converge in the Sun-Earth-Moon N-body model (with states described in GCRF). I haven’t looked into the CR3BP version though.

The major issues are:

  1. scaling of the constraints vector and Jacobian matrix before computing the update
  2. Solution of the (under-determined) linear system for the update: using Cholesky decomposition rather than explicit matrix inversion prevents the algorithm from divergence
  3. constant arc duration on “extreme” cases

More details in the issue you pointed to me: Multiple issues in multiple shooting (#876) · Issues · Orekit / Orekit · GitLab

Best regards,

Thank you very much Alberto. We would be very happy to include your fix and contribution in Orekit.

If you’re interested in contributing the code, could you:

  1. Follow the steps of the contribution guide in order to propose a Merge Request
  2. Send me an Individual Contributor License Agreement (ICLA)?

orekit_ICLA.doc (39 KB)

For the ICLA, you can send it to my email:

If you have any question, don’t hesitate.

Best regards,

I will contribute to the code.

Just to be sure we agree on the developments, I will include the following fixes/additions:

  1. Linear system solution: allow under-determined systems, replace explicit matrix inversion, scaling of Jacobian and constraints based on a reference time and length
  2. Different propagation times for different arcs
  3. Sign error in epoch derivatives
  4. Patch point indexing from 0 (documented)

I have also a question from the implementation point of view:
For autonomous systems, like the CR3BP, the epochs and epochs constraints are omitted from the free variables and constraint vectors, so the last as well as the Jacobian have different dimensions for the same number of patch points. Moreover, few computations are skipped while filling these vectors and matrices at each iteration. At present, this is handled with a series of if/else statements in the corresponding methods implemented in AbstractMultipleShooting.
For me it would be more clear handling this with inheritance rather than if/else, although it may require two additional abstract classes for autonomous and non-autonomous systems respectively (unless we assume the CR3BP is the only autonomous system we will have to deal with in this context, and all non-autonomous systems are handled by the current MultipleShooter class). What do you think?

Best Regards,