Constant Maneuver Basic Constant Thrust duration issue

Orekit usage
1

Hello Orekit team,
I join the people who thanks you guys for the great work!

I work for GomSpace and we do use Orekit to develop some applications that requires Orbital Propagation.

I am now entering in the mined field of the Orbital Maneuvers.
I performed some tests and I realized two issues.

I start from the example stored in the tutorial:
https://www.orekit.org/site-orekit-tutorials-development/tutorials/maneuvers.html

The second case: Continuous Maneuver and I perform some changes.

I propagate from the following orbit
//Departure Orbit elements
double a = 7000000.0; //[m]
double e = 0.00; //[-]
double i = FastMath.toRadians(70.0); //[rad]
double Om = FastMath.toRadians(50.0); //[rad]
double om = FastMath.toRadians(10.0); //[rad]
double nu = FastMath.toRadians(275.0); //[rad]

(just copy pasting the code from the tutorial, and modifying spacecraft mass, burn duration and thrust value)

//Build state (smaller mass)
final SpacecraftState initialState = new SpacecraftState( equinoctialOrbit, 20);

//Build propagator
final OrbitType orbitType = OrbitType.EQUINOCTIAL;
final double[][] tol = NumericalPropagator.tolerances(1.0, equinoctialOrbit, orbitType);

//Build integrator
final AdaptiveStepsizeIntegrator integrator =
  new DormandPrince853Integrator(0.001, 1000, tol[0], tol[1]);
integrator.setInitialStepSize(60);
final NumericalPropagator propagator = new NumericalPropagator(integrator);
propagator.setOrbitType(orbitType);
propagator.setInitialState(initialState);
propagator.setAttitudeProvider(new LofOffset(FramesFactory.getEME2000(), LOFType.VNC));

if (DEBUG) {
  //DEBUG print
  propagator.setMasterMode(.5, (state, isLast) ->
    System.out.format("%s a = %12.3f m, r = %12.3f m, e = %11.9f, i = %11.9f, m = %8.3f kg,  nu = %11.9f rad%n",
      state.getDate(), state.getA(), state.getPVCoordinates(FramesFactory.getEME2000()).getPosition().getNorm(),
      state.getE(), state.getI(), state.getMass(), normalizeAngle(state.getLv() - startOrbit.Om - startOrbit.om))
  );
}

//Build firing force model
final AbsoluteDate firingDate = new AbsoluteDate(new DateComponents(2021, 2, 21), new TimeComponents(1, 29, 34.080), TimeScalesFactory.getUTC());
//Really small duration (in sec)
final double duration = 0.009;
final ManeuverTriggers triggers = new DateBasedManeuverTriggers(firingDate, duration);

//Thruster properties (big thrust)
final double thrust = 5420; final double isp = 318;
final PropulsionModel propulsionModel = new BasicConstantThrustPropulsionModel(thrust, isp, Vector3D.PLUS_I, "apogee-engine");
propagator.addForceModel(new Maneuver(null, triggers, propulsionModel));

//Propagate
propagator.propagate(firingDate.shiftedBy(-900), firingDate.shiftedBy(duration + 900));

I basically increase a lot the thrust value (to 5420 for instance) and reduce the mass (to 20 kg)
The evaluated flow rate in the propulsionModel is = -1.73 kg/s and setting the duration of the burn as 0.009 I should not consume all the mass.
On the contrary, running the code I received this message:
spacecraft mass becomes negative: -62.278

It seems it burned for around 47.55 seconds (as dM = 82.278, q = -1.73, dt = dM/q)
Am I setting something wrong?

Morevore, second issue, if I increase the mass, lets put = 2000, with same settings I have the error:
hyperbolic orbits cannot be handled as org.orekit.orbits.EquinoctialOrbit instances

In this case I have maybe set too strong impulse and so the eccentricity is > 1. But I feel that the problem is in the duration because acceleration for such a small duration the DV (calculated by hand) is not enough to change the eccentricity.

Thanks in advance for the support
Alberto

2

Hi @alberto-ferrero,

I think the issue here is that the maneuver is too “impulse-like” for your integrator. After the maneuver has been triggered, it is trying to evaluate next step with a step-size that is too large (47.55s it seems) with the maneuver on.
Since it considers the maneuver is on, you get a negative mass in the first case and an hyperbolic orbit in the second case.
My guess is you need to constrain the integrator a bit more for such a short and intense maneuver.

I have just tried to change:

final AdaptiveStepsizeIntegrator integrator =
  new DormandPrince853Integrator(0.001, 1000, tol[0], tol[1]);

With changing the maximum step size to 1s instead of 1000s:

final AdaptiveStepsizeIntegrator integrator =
  new DormandPrince853Integrator(0.001, 1., tol[0], tol[1]);

And it seems to work: no exception and a mass consumption of 16g.

Hope this helps,
Maxime

3

Thanks a lot Maxime!
So it was an issue on convergence. As often there is a need of balance between performances (CPU) and precision.
Kind regards
Alberto