Improved "AoA vs CAS.ipynb" example
Updated "AoA vs CAS.ipynb" example. PNG images embedded inside the Jupyter notebook.
Added more context at the beginning of the notebook. Added more figures taken from JSBSim online reference manual. Made a first plot of trimmed states with one weight and one x-cg. Improved the original plot.
@agodemar you don't need to open a new PR when you are making changes to a PR. Just update the code in your branch (master in your case) and the PR will update accordingly.
Yep, and it doesn't matter if there a bunch of commits to get things right, we'll do a squash merge so all the individual commits won't be visible in JSBSim's master branch once we merge it in.
In terms of your Matplotlib figures not originally being included and visible in the Jupyter notebook it looked like you hadn't executed the notebook before the commit since there was no execution count for the code cells.
The best option to ensure that you have all the required outputs in the notebook and also to ensure that the output of each code cell actually matches the code is to perform a "Restart Kernel and run all cells" before each commit.
PNG images embedded inside the Jupyter notebook.
The static PNG images aren't embedded in the notebook, the notebook has references to the PNG images in the images directory, e.g. from the notebook.
<img src=\"images/ac_sideview_climb_1.png\
If an image is actually embedded in the notebook then you will see the image data base64 encoded inside the .ipynb file, e.g. like the following for the Matplotlib output images from the code cells.
"data": {
"image/png": "iVBORw0KGgoAAAANSUhEUgAA........
For the static PNG images there are some pros and cons in terms of having them actually embedded in the .ipynb file versus being links to external image files. If they are embedded then you can pass around/email a single .ipynb file to someone. But if multiple notebooks may use some of the same static image files then it might be better to have them all reference a single external image file, the ipynb file is smaller etc.
Given we have a lot more context up-front now I think we should then also have a brief explanation section after the output graphs to explain why the graphs look the way they do, in particular to do with the graph's range $V_{min}$ - $V_{max}$ for a particular configuration.
For example, maybe something along these lines:
For a given configuration $V_{max}$ will be limited by the available engine thrust as the drag increases with increasing airspeed. $V_{min}$ will typically have a number of factors that limit how slow the aircraft can be trimmed for level flight. As the airspeed decreases a larger AoA is required in order to generate enough lift to balance the weight. So one limit is $C_{L_{max}}$, i.e. the AoA defining the start of a stall. Even if $C_{L_{max}}$ isn't reached, as the AoA is increased the drag rises significantly and so engine thrust can also be a limiting factor. Lastly elevator/stabilizer power may not be sufficient in order to achieve the required AoA. Also mention the role of varying cg.....
In fact, looking at the current graphs, it's not immediately clear to me what is limiting $V_{max}$ for the +5% cg cases.
For a given configuration V m a x will be limited by the available engine thrust as the drag increases with increasing airspeed. V m i n will typically have a number of factors that limit how slow the aircraft can be trimmed for level flight. As the airspeed decreases a larger AoA is required in order to generate enough lift to balance the weight. So one limit is C L m a x , i.e. the AoA defining the start of a stall. Even if C L m a x isn't reached, as the AoA is increased the drag rises significantly and so engine thrust can also be a limiting factor. Lastly elevator/stabilizer power may not be sufficient in order to achieve the required AoA. Also mention the role of varying cg.....
Yes, I agree with your observations. They demonstrate what is known to aerospace engineers from Flight Mechanics courses, in particular from basic concepts of level flight performance.
Also, these notebooks should provide to the general audience some practical examples of how a fairly advanced flight simulation tool (such as JSBSim coupled with Python & Jupyter) is able to reproduce annotated engineering simulations with a reasonable effort.
I will keep working on refining this first example.
I've always been a bit suspicious of the outputs for this example for the +5% cg cases, but have never taken a closer look. Given we're updating the example I'll take a closer look to try and understand what is happening with the +5% cg cases and how realistic the results are.
The fcs/throttle-cmd-norm and fcs/throttle-cmd-norm[1] should also be displayed.
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 24.76%. Comparing base (024046d) to head (4683265).
:warning: Report is 12 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #1290 +/- ##
=======================================
Coverage 24.76% 24.76%
=======================================
Files 169 169
Lines 19598 19598
=======================================
Hits 4854 4854
Misses 14744 14744
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.