aerodynamic_analysis (schueltke): corrected wave drag calibration and neutral point estimation
Description
- corrected wave drag calibration (the calibration is only applied, when the uncalibrated polar shows wave drag)
- corrected function call of neutral point estimation with correct trimmed polar
Related Issue(s)
N.A
Other Changes
N.A
Screenshots/Logs
N.A
Testing Instructions
- download this branch and build aerodynamic_analysis
- run module on already converged aircraft design
- the output of drag polars for a delta stabilizer angle of 0 deg should be 0 in wave drag for the whole Ma=0.2 and Ma=0.5 polar. First wave drag occurrences from Ma=0.6 on (before also for Ma=0.2 and Ma=0.5 wave drag was calculated)
- the neutral point should be equivalent to the design mass CG now for a trimmed polar (static_margin of 0)
Developer Checklist
-
Code has been tested locally and/or in pipeline. -
Merge conflicts resolved with the target branch.
Additional Notes
N.A
Merge request reports
Activity
changed milestone to %Milestone Final v0.5
added moduleaerodynamic_analysis typebug labels
requested review from @maren.huxel
assigned to @maurice.zimmnau
enabled an automatic merge when all merge checks for b29d4178 pass
I am just wondering: Does that mean that in a clean sheet design just at the beginning of the design when you have no calibration the wave drag would still be there at low Mach numbers? And another thing. With this change the static_margin would be zero. But that would mean we have an neutral stable aircraft. Which should not be the case. I think I did not make it to clear yesterday. If CM=0 for all points, which is the case for the trimmed polar, I think we need a different approach to calculate it.
-
no, also in the first iterations we have only wave drag up to certain Mach numbers. The idea to use a converged aircraft here to test it was that you do not have to execute all the other tools up to aerodynamic_analysis. But of course, the behaviour for a clean sheet design in WF is the same
-
yes, it makes no sense. The way we had it before (faulty or not) was to calculate it only for a stabilizer position of 0 deg (if trimming is active) or the given position in aircraft XML (if trimming is not active). Should we switch it back to this or do you have a better idea for now?
-
- Resolved by Florian Schültke
aborted the automatic merge because the source branch was updated. Learn more.
added 1 commit
- e485dfa4 - reverted change as discussed --> to be clarified for final release
mentioned in commit d7bc4831