-
-
Notifications
You must be signed in to change notification settings - Fork 193
ENH: Add the Coriolis Force to the Flight class #799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
the wind factor wasn't applied to the env.wind_velocity properties
It showed the nominal and the standard deviation values and it doesn't make sense in a uniform distribution. In a np.random.uniform the 'nominal value' is the lower bound of the distribution, and the 'standard deviation' value is the upper bound. Now, a new condition has been added for the uniform distributions where the mean and semi range are calculated and showed. This way the visualize_attribute function will show the whole range where the random values are uniformly taken in
Added the ability to multiply functions with 2D domains in the __mul__ function
The StochasticAirBrakes class has been created. The __init__.py files in the stochastic and rocketpy folders have also been modified accordingly to incorporate this new class
This functions appends an airbrake and controller objects previuosly created to the rocket
ENH: Merge enh/set-air-brakes-function
ENH: Merge enh/multiply_2D_functions
Some functions has been modified and other has been created in order to include the new StochasticAirBrakes feature into the StochasticRocket class. A new function named 'add_air_brakes' has been created to append a StochasticAirBrakes and Controller objects to the StochasticRocket object. A new function '_create_air_brake' has been introduced to create a sample of an AirBrake object through a StochasticAirBrake object. Enventually, the 'create_object' function has been modified to add the sampled AirBrakes to the sampled Rocket
When defining the _Controller object a StochasticAirBrake was input. This is already corrected and a AirBrake object is now introduced
…ontroller BUG: StochasticAirBrake object input in _Controller
Since the new StochasticAirBrake class is defined, we need the 'time_overshoot' option in the Flight class to ensure that the time step defined in the simulation is the controller sampling rate. The MonteCarlo class has had to be modified as well to include this option.
Documentation related to the StochasticAirBrakes implementation has been added in StochasticAirBrakes, StochasticRocket and Rocket classes.
ENH: ruff modifications
Unnecessary comment Co-authored-by: Gui-FernandesBR <[email protected]>
Co-authored-by: MateusStano <[email protected]>
Co-authored-by: Gui-FernandesBR <[email protected]>
Co-authored-by: MateusStano <[email protected]>
…/kevin-alcaniz/RocketPy into enh/stochastic-airbrakes-feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good to me...
Please don't forget to update the CHANGELOG as well.
I hope one day we implement the autochangelog tool in this repo :)
Co-authored-by: Gui-FernandesBR <[email protected]>
…Team/RocketPy into enh/add-inertial-forces
@Gui-FernandesBR All good on my side!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, @kevin-alcaniz !
From my point of view, this PR adds great value to RocketPy.
@MateusStano would like to review this PR before we proceed to merging it onto develop.
Tests are failing, this happens because some tests have values that were made by running flight and capturing the results. Since the flight simulation has changed with this PR, we have to update the values.
@kevin-alcaniz I know you've been busy, so don't worry, I believe we can work on this problem from our side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (2)
rocketpy/simulation/flight.py:1696
- [nitpick] Consider explicitly indicating the discarded x component (perhaps with a named placeholder like '_x') for clarity. This would help ensure that the component order is immediately clear to readers and maintainers.
_, w_earth_y, w_earth_z = self.env.earth_rotation_vector
rocketpy/simulation/flight.py:1921
- [nitpick] Verify that the coordinate transformation via Kt applied here produces results consistent with the manual component handling in the u_dot method. Ensuring consistency in handling the Earth's rotation vector across methods is crucial for correct Coriolis force computation.
w_earth = Kt @ Vector(self.env.earth_rotation_vector)
Thank you, @Gui-FernandesBR , I appreciate it! Sure. I'm looking forward to the third check. If you have any doubts or suggestions, please, let me know. |
Before we start working on updating the tests, does any of you have anything to say regarding this PR, @phmbressan @MateusStano ? another review would be appreciated here. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #799 +/- ##
===========================================
+ Coverage 79.11% 80.11% +0.99%
===========================================
Files 96 98 +2
Lines 11575 12057 +482
===========================================
+ Hits 9158 9659 +501
+ Misses 2417 2398 -19 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Really awesome @kevin-alcaniz! I took the liberty to add everything that was missing here since it had been so long. From you implementation though, there was only one mistake: you were applying an extra unnecessary rotation to the earth_rotation_vector. Taking that out made the simulation behavior make more sense. I also added the coriolis effect to the parachute udot. For documentation purposes here is a few plots exemplifying the correct expected behavior with the Coriolis acceleration. The simulation here has no wind, no parachutes, and no aerodynamic forces (0 drag and no aero surfaces)
Now some cases showing the effect of north vs south hemisphere. The expected behavior can be seen from analyzing the added acceleration from the Coriolis effect (written in the Flight Coord System): Wherever the For
Now we just a need a final approve and we can merge this! @Gui-FernandesBR @phmbressan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update changelog
Pull request type
Checklist
black rocketpy/ tests/
) has passed locallypytest tests -m slow --runslow
) have passed locallyCHANGELOG.md
has been updated (if relevant)Current behavior
Currently, RocketPy doesn't account for the Coriolis force, even though the Flight Coordinate System is not truly an inertial reference frame.
New behavior
Environment
class:A new attribute has been added: the Earth's angular velocity vector. Additionally, a new function has been implemented to compute it.
Flight
class:The Coriolis acceleration has been added to the
vdot
vector in theu_dot_generalized
function. A theoretical explanation justifying this implementation is attached below.Breaking change
Theory