Skip to content

BUG: MonteCarlo drops StochasticFlight solver and termination settings #1150

Description

@ting-hong-shieh

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

  1. Create a Flight with non-default solver or termination settings, such as a custom max_time, max_time_step, rtol, or ode_solver.
  2. Wrap it in StochasticFlight and run one Monte Carlo simulation.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions