Multiple issues in multiple shooting
The AbstractMultipleShooting
class and its derived classes MultipleShooter
and CR3BPMultipleShooter
have multiple issues.
- they rely on specific additional equations (
EpochDerivativesEquations
forMultipleShooter
andSTMEquations
forCR3BPMultipleShooter
) and performs cast blindly instead of using proper typing in constructors - the API use patch numbers counting from 1 and component index counting from 0 in the same methods, which is not documented and confusing
- they switch patch points coordinates to free/fixed all components at a time, while allowing setting fixed value for each component thus leading to inconsistent settings (i.e. you can set patch point 2 as free, but fix its y component)
- due to the previous item, the linear algebra used in the resolution assumes some variables are free when they are not
- there are only few tests, and the only one for
CR3BPMultipleShooter
fails if maxIterations is greater than 1 (it succeeds in 1 iterations, but the results are dubious) - it seems that equation 3.48 in Pavlak's thesis has a sign error (-∂xᵀ₂/∂τ₁ should probably be +∂xᵀ₂/∂τ₁)
-
EpochDerivativesEquations
relies on a specific force model (ThirdBodyAttractionEpoch
) to be present, and in the tests this model seems to be ill-configured - derivatives with respect to epoch should probably be computed using the same expression as in maneuvers with
current STM given by a
MatricesHarvester
and initial derivatives picked up at propagation start time: ∂y/∂t₀ = -∂y/∂y₀ f(t₀, y₀) - setting closed orbit constraint generates index out of bound exceptions and does not seem to work
- the multiple shooting abstract class should probably be located in the
propagation.integration
package rather than theutils
package
The additional equations types issue has been partly addressed in 11.1 but needs incompatible signature changes for completion, so it should wait for version 12.0.
Anyway, this feature would probably need to be completely redesigned.
Edited by Luc Maisonobe