BUG: draw each declared eccentricity once per simulation - #1168
Merged
Gui-FernandesBR merged 1 commit intoAug 15, 2026
Merged
Conversation
RocketPy-Team#1167 declared the eccentricities that add_cp_eccentricity and add_thrust_eccentricity install, so dict_generator draws them. _create_eccentricities then drew them a second time and overwrote the first value. The exported inputs matched the applied ones only because the second write wins, and the extra draw moved every component position create_object places after it. Read what has been drawn already, and draw only a half the caller left out, which is not a declared input and so never reaches dict_generator. The docstring correction is the explanation RocketPy-Team#1167 landed with, which named the wrong symptom: the value did vary between simulations, what a fixed seed failed to do was reproduce it. Signed-off-by: thc1006 <84045975+thc1006@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1168 +/- ##
===========================================
+ Coverage 84.44% 84.54% +0.09%
===========================================
Files 131 131
Lines 17491 17497 +6
===========================================
+ Hits 14771 14792 +21
+ Misses 2720 2705 -15 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Gui-FernandesBR
approved these changes
Aug 15, 2026
This was referenced Aug 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request type
Checklist
ruff check/ruff format) has passed locallypytest tests -m slow --runslow) have passed locally, apart from the pre-existing failures listed belowCHANGELOG.md: no action needed, an LLM workflow auto-updates it after mergeCurrent behavior
The follow-up @Gui-FernandesBR asked for in #1167 (comment).
#1167 declared the eccentricities that
add_cp_eccentricityandadd_thrust_eccentricityinstall, sodict_generatornow draws them.create_objectthen calls_create_eccentricities, which draws them a second time and overwrites the first value inlast_rnd_dict.The exported inputs still match the applied ones, because the second write wins. What the extra draw costs is stream position.
_create_eccentricitiesruns before the motor, surface and rail button loops, so every component positioncreate_objectplaces after it moves too.Nose cone position,
stochastic_calisto, seed 42:developFour declared on this branch lands on two declared on
develop, bit for bit, and so do the motor and lower rail button positions. Both consume four extra draws ahead of the component loops, which is the whole of the effect.New behavior
_create_eccentricitiesreads a half thatdict_generatorhas drawn already, and draws only a half the caller left out.That second case is the reason this is not a plain dictionary lookup.
add_cp_eccentricity(x=...)with noyis documented and supported, andyis then not a declared input, so it never reachesdict_generator. Reading the dictionary unconditionally raisesKeyErroron that call and dropscp_eccentricity_yfrom the exported inputs, whichdevelopreports today.test_an_eccentricity_half_that_was_left_out_is_still_drawnholds that shut.The docstring correction in
test_an_eccentricity_added_after_init_is_still_drawnis the explanation from your #1167 review: the value did vary between simulations, what a fixed seed failed to do was reproduce it.Breaking change
Fixed-seed baselines that declare an eccentricity move: the eccentricity values themselves, and every component position placed after them. Runs with no eccentricity are untouched, and so is anything drawn from a submodel's own generator. #1167 is not in a release yet and
[Unreleased]already carries two entries that move fixed-seed baselines (#953 and #1102), so this folds into the same re-baseline rather than asking for a second one later.Additional information
test_a_declared_eccentricity_is_not_drawn_a_second_timefails on unmodifieddevelop, with all four values wrong.test_an_eccentricity_half_that_was_left_out_is_still_drawnpasses there, and fails on the version that reads the dictionary unconditionally.Local checks on
24861fdf, Linux, Python 3.13:ruff check .andruff format --check .clean, ruff 0.15.20pylint rocketpy/ tests/ docs/10.00/10, exit 0pytest tests/unit2080 passed,pytest rocketpy --doctest-modules48 passed,pytest tests/integration153 passed,pytest tests/acceptance18 passedpytest tests -m slow --runslow38 passed, 5 failed. The five are theEnvironmentAnalysistests, and they fail the same way on an unmodified24861fdfhere.test_monte_carlo_simulate[True]also hangs on an unmodified24861fdfon this machine, in a forked worker, so it is deselected from that count rather than reported as a pass.