Fix level2 detailed takeoff example #914
Open
+48
−13
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.
Summary
This PR improves and fixes the level-2 FLOPS-based detailed nominal takeoff example.
fix_initial=Truefor the mass state in the FLOPS ground-roll phase. Now it overrides the mass state tofix_initial=Falseand add an equality constraint to imposeinitial mass state = mission:summary:gross_mass.num_segmentsand optimizer settings so the level-2 detailed takeoff example converges.Questions
In the height-energy problem configurator, the mass link constraint is only added when the simple takeoff component is not added. I'm not sure if we should do the same for the solved-2DoF configurator (I guess the question comes down to: do we ever use the simple takeoff comp along with solved-2DoF EoM for main mission, or solved-2DoF is exclusively for FLOPS detailed takeoff?)
Also the height-energy configurator adds the range and mass residual constraints but the solved-2DoF configurator does not. This works fine for my case because I only use solved-2DoF mission for takeoff, but if the solved-2DoF phases are intended to cover the entire mission, range and mass residual constraints would be required. Currently a user would have to manually add these in their runscript (which in my opinion perfectly fine)
Note
It might also help other cases if we set a default
limited_memory_max_historyin Aviary's set_driver method. This is analogous to SNOPT'sHessian frequency. IPOPT's default for this parameter is 6, but in my experience carrying more history for Hessian approximation improves convergence.Related Issues
Backwards incompatibilities
None
New Dependencies
None