BUG: the rocket does not take off the rail

Describe the bug

I did everything correctly when creating my Flight object, but for some reason the rocket doesn't fly.
I guess this is happening because my thrust curve doesn't start at time == 0 seconds
Therefore the SciPy's integrator adopts really large time steps, which make the thrust curve to be ignored.

To Reproduce

Try to follow the code block below. You're gonna see that the rocket never leaves the position (0, 0, 0).

liquid_motor = LiquidMotor(
        thrust_source="data/SEBLM/test124_Thrust_Curve.csv",
        burn_time=(8, 20), # this is important to reproduce the error!
        dry_mass=10,
        dry_inertia=(5, 5, 0.2),
        center_of_dry_mass_position=0,
        nozzle_position=-1.364,
        nozzle_radius=0.069 / 2,
    )
liquid_motor.add_tank(pressurant_tank, position=2.007)
liquid_motor.add_tank(fuel_tank, position=-1.048)
liquid_motor.add_tank(oxidizer_tank, position=0.711)

calisto_liquid_modded= Rocket(
        radius=0.0635,
        mass=14.426,
        inertia=(6.321, 6.321, 0.034),
        power_off_drag="data/calisto/powerOffDragCurve.csv",
        power_on_drag="data/calisto/powerOnDragCurve.csv",
        center_of_mass_without_motor=0,
        coordinate_system_orientation="tail_to_nose",
    )
calisto_liquid_modded.add_motor(liquid_motor, position=-1.373)

test_flight = Flight(
        rocket=calisto_liquid_modded,
        environment=Environment(),
        rail_length=5,
        inclination=85,
        heading=0,
        max_time_step=np.inf # this is important to reproduce the error!
)

test_flight.all_info()

Expected behavior

A description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Some warning are also generated due to this BUG, for example:

tests/test_flight.py::test_liquid_motor_flight
  RocketPy\rocketpy\plots\flight_plots.py:107: UserWarning: Attempting to set identical low and high zlims makes transformation singular; automatically expanding.
    ax1.set_zlim3d([0, max_z])

tests/test_flight.py::test_liquid_motor_flight
  RocketPy\rocketpy\plots\flight_plots.py:108: UserWarning: Attempting to set identical low and high ylims makes transformation singular; automatically expanding.
    ax1.set_ylim3d([min_xy, max_xy])

tests/test_flight.py::test_liquid_motor_flight
  RocketPy\rocketpy\plots\flight_plots.py:109: UserWarning: Attempting to set identical low and high xlims makes transformation singular; automatically expanding.
    ax1.set_xlim3d([min_xy, max_xy])

Possible solutions:

While discussing this internally, we came up with some suggestions:

We could set the max_time_step as 0.1 * burn_duration, for example, to ensure that any simulation will have at least 10 steps.
The default value of max_time_step could now be set to 0.1 instead of np.inf
We could stop initializing the flight simulations at t=0s, instead, starting it at t= burn_time[0]

I think it's not a good idea to start the simulation with a initial_time different of t=0.
Otherwise, we would lose some insights in the flight, for example, the "apogee_time" would become the flight time plus the time until ignition starts. This would be a bit confusing I guess.

It's better to adjust the thrust curve to always start at 0, probably.

I'm open to discussions anyway

This bug happens to me frequently even when the thrust curve starts with 0. The way I fix it is the same as suggested (changing the maxTimeStep to 0.1) as shown in the screenshot

The simulations of this screenshot had a thrust curve that starts like this

In Monte Carlo simulations this also happens sometimes, usually when the standard deviation of the burn time is too high. To correct the dispersion analysis, I have to reduce the standard deviation.

I've encountered the same error when trying to simulate a low-powered rocket, but this time, even after setting the maxTimeStep to 0.1, it only partially mitigated the issue, as I still encounter the following error:

"
File c:\Users....conda\lib\site-packages\numpy\lib\function_base.py:630, in asarray_chkfinite(a, dtype, order)
628 a = asarray(a, dtype=dtype, order=order)
629 if a.dtype.char in typecodes['AllFloat'] and not np.isfinite(a).all():
--> 630 raise ValueError(
631 "array must not contain infs or NaNs")
632 return a

ValueError: array must not contain infs or NaNs
"

Additionally, the original issue of the rocket failing to leave the rail persists in Monte Carlo simulations, even with a very low standard deviation for all parameters.

@Exsthain

I've encountered the same error when trying to simulate a low-powered rocket, but this time, even after setting the maxTimeStep to 0.1, it only partially mitigated the issue, as I still encounter the following error:

" File c:\Users....conda\lib\site-packages\numpy\lib\function_base.py:630, in asarray_chkfinite(a, dtype, order) 628 a = asarray(a, dtype=dtype, order=order) 629 if a.dtype.char in typecodes['AllFloat'] and not np.isfinite(a).all(): --> 630 raise ValueError( 631 "array must not contain infs or NaNs") 632 return a

ValueError: array must not contain infs or NaNs "

Additionally, the original issue of the rocket failing to leave the rail persists in Monte Carlo simulations, even with a very low standard deviation for all parameters.

Hello @Exsthain ,

The error you have indicated is being raised from numpy. Without a context, it is impossible to understand what generated the error in first place, nor reproduce it.

Have you tried to set an even smaller max_time_step ?

My recommendation is for you to debug the code focusing on the u_dot_rail1 method.

@Gui-FernandesBR

Hey @Gui-FernandesBR , I was looking into this issue and noticed that burn_start_time is never added as a flight phase boundary. With max_time_step=np.inf, the integrator can skip right over the burn window without ever "seeing" the thrust. I was thinking the cleanest fix would be to add a phase at burn_start_time when it's greater than t_initial, so the solver is forced to stop there and restart. From that point on, with non-zero thrust, the adaptive integrator handles the rest naturally. Do you think that's the right direction, or do you prefer changing the default max_time_step to something like 0.1? The phase boundary approach feels less invasive since it doesn't affect performance for motors that start at t=0.

Hey @Gui-FernandesBR , I was looking into this issue and noticed that burn_start_time is never added as a flight phase boundary. With max_time_step=np.inf, the integrator can skip right over the burn window without ever "seeing" the thrust. I was thinking the cleanest fix would be to add a phase at burn_start_time when it's greater than t_initial, so the solver is forced to stop there and restart. From that point on, with non-zero thrust, the adaptive integrator handles the rest naturally. Do you think that's the right direction, or do you prefer changing the default max_time_step to something like 0.1? The phase boundary approach feels less invasive since it doesn't affect performance for motors that start at t=0.

yes I think that's in the right direction! If you could ensure all the tests passing after your modifications, feel free to raise a PR. I will be glad reviewing it :)

Confirmed this still reproduces on develop, and I have a fix — will open a PR shortly.

Minimal repro (same rocket and total impulse, only the thrust curve's start time differs):

[thrust starts t=0] out_of_rail_t=0.329  out_of_rail_v=23.96  apogee=10329 m
[thrust starts t=8] out_of_rail_t=0.000  out_of_rail_v=0.00   apogee=0 m   <- never leaves the pad

Root cause (matches your original diagnosis): the rail phase's only time nodes are [t=0, max_time]. With no thrust at t=0 the rocket is stationary, so LSODA (max_step defaults to inf) takes one huge step that jumps clean over the t=8 burn — the thrust is never sampled and the rocket never lifts off.

Fix: force a solver time node at the motor's ignition and burn-out whenever burn_start_time > 0, so the burn is always sampled. Guarded to late-starting motors, so ordinary motors (burn_start_time == 0) are byte-for-byte unaffected. With the fix the delayed case flies identically to the t=0 case, just shifted: out_of_rail_t=8.329, apogee=10329 m.

BUG: rocket with a late-starting thrust curve never leaves the rail (#…

This was fixed on `develop` by #1085 (`335834d8`). Late-starting thrust curves (e.g. `burn_time=(8, 20)`) should leave the rail correctly now. Please close if you can still reproduce on current `develop`.

This was fixed on develop by #1085 (335834d8). Late-starting thrust curves (e.g. burn_time=(8, 20)) should leave the rail correctly now. Please close if you can still reproduce on current develop.

true

BUG: stop the solver at motor ignition and burnout (#411)

Navigation Menu

Repository navigation

BUG: the rocket does not take off the rail #411

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

BUG: the rocket does not take off the rail #411

Description

Activity

Gui-FernandesBR commented on Sep 16, 2023

williambrenner commented on Sep 16, 2023

Exsthain commented on Feb 14, 2025

Gui-FernandesBR commented on Feb 14, 2025

YuriCastroDev commented on Jun 19, 2026

Gui-FernandesBR commented on Jun 19, 2026

wuisabel-gif commented on Jul 22, 2026

thatrandomasiandev commented on Aug 11, 2026

Gui-FernandesBR commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions