Bug #350

Difference in behavior between NumericalPropagator.addForceModel() and FieldNumericalPropagator().addForceModel()

Added by Evan Ward 3 months ago. Updated 3 months ago.

Status:ResolvedStart date:2017-08-11
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Running

NumericalPropagator np = ...;
np.addForceModel(new NewtonianAttraction(...));

will replace the current central attraction force instead of adding a new force model. On the other hand

FieldNumericalPropagator<> fnp = ...;
fnp.addForceModel(new NewtonianAttraction(...));

will add an additional copy of the central attraction force, making the satellite orbit around the Earth twice as fast. The code in FNP seems much simpler than the code in NP, so perhaps the best solution is to just add a note of the difference in behavior to the method comment for FNP.addForceModel().

History

#1 Updated by Luc Maisonobe 3 months ago

  • Status changed from New to Resolved

Fixed in git repository (see 90ff73a5), merged into develop branch (see 933bd52d).

I have used the same logic as per NumericalPropagator, i.e. the Newtonian attraction is stored
at the end of the force models list and care is taken to update it correctly, when either it
is added as a force model, set using setMu, or set at propagation start using the initial
state central attraction coefficient.

Indeed, we will need to manage this even more specially when we will merge the work currently
done in the SOCIS program by a student. He works on trajectories around Lagrange points and
there you don't really have one main central attraction, you have two bodies, and you may
integrate in a frame that is neither bodies center. So having already a similar logic in
FieldNumericalPropagator and NumericalPropagator seemed simpler for the future merge.

Also available in: Atom PDF