Describe the bug
MonteCarlo.__run_single_simulation() constructs Flight directly instead of using StochasticFlight.create_object(). The direct constructor forwards the randomized rocket, environment, rail length, inclination, heading, initial solution, apogee termination flag, and time_overshoot, but drops these settings from the source Flight:
max_time
max_time_step
min_time_step
rtol
atol
name
equations_of_motion
ode_solver
simulation_mode
StochasticFlight.create_object() already preserves those fields, but it currently uses the nominal rocket and environment and therefore cannot be called directly by MonteCarlo, which must supply the independently randomized objects.
To reproduce
- Create a
Flight with non-default solver or termination settings, such as a custom max_time, max_time_step, rtol, or ode_solver.
- Wrap it in
StochasticFlight and run one Monte Carlo simulation.
- Inspect the
Flight constructed by MonteCarlo.__run_single_simulation().
At cb6106a717207dd8fc2dfe1446d80ff75022f21b, the omitted fields fall back to Flight defaults rather than the values selected for the source flight.
Expected behavior
A Monte Carlo sample should change only the declared stochastic inputs. Solver, termination, equation-of-motion, simulation-mode, and naming settings should match the source Flight unless they are explicitly randomized.
Proposed fix
Make StochasticFlight.create_object() the canonical construction path. Allow it to accept randomized rocket and environment overrides, then have MonteCarlo create those two objects and pass them to the factory. This avoids maintaining a second, incomplete Flight(...) argument list.
Regression tests should use non-default values for every preserved field and verify both the direct StochasticFlight factory and the Monte Carlo path.
This overlaps the flight-construction area changed by #1126, so implementation should follow that pull request rather than competing with it.
Environment
- Base SHA:
cb6106a717207dd8fc2dfe1446d80ff75022f21b
- RocketPy 1.13.0
- Python 3.12.6
- NumPy 2.5.2
- SciPy 1.18.0
- pytest 9.1.1
- macOS 26.5.2, arm64
Describe the bug
MonteCarlo.__run_single_simulation()constructsFlightdirectly instead of usingStochasticFlight.create_object(). The direct constructor forwards the randomized rocket, environment, rail length, inclination, heading, initial solution, apogee termination flag, andtime_overshoot, but drops these settings from the sourceFlight:max_timemax_time_stepmin_time_steprtolatolnameequations_of_motionode_solversimulation_modeStochasticFlight.create_object()already preserves those fields, but it currently uses the nominal rocket and environment and therefore cannot be called directly byMonteCarlo, which must supply the independently randomized objects.To reproduce
Flightwith non-default solver or termination settings, such as a custommax_time,max_time_step,rtol, orode_solver.StochasticFlightand run one Monte Carlo simulation.Flightconstructed byMonteCarlo.__run_single_simulation().At
cb6106a717207dd8fc2dfe1446d80ff75022f21b, the omitted fields fall back toFlightdefaults rather than the values selected for the source flight.Expected behavior
A Monte Carlo sample should change only the declared stochastic inputs. Solver, termination, equation-of-motion, simulation-mode, and naming settings should match the source
Flightunless they are explicitly randomized.Proposed fix
Make
StochasticFlight.create_object()the canonical construction path. Allow it to accept randomizedrocketandenvironmentoverrides, then haveMonteCarlocreate those two objects and pass them to the factory. This avoids maintaining a second, incompleteFlight(...)argument list.Regression tests should use non-default values for every preserved field and verify both the direct
StochasticFlightfactory and the Monte Carlo path.This overlaps the flight-construction area changed by #1126, so implementation should follow that pull request rather than competing with it.
Environment
cb6106a717207dd8fc2dfe1446d80ff75022f21b