-
Notifications
You must be signed in to change notification settings - Fork 68
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
Added a balanced field length example #533
Conversation
…ectory parameters appears to be broken.
… timeseries plots with undefined label on the xaxis
…, polynomial controls, parameters, and times are sticking.
|
||
|
||
@use_tempdirs | ||
class TestBalancedFieldLengthRestart(unittest.TestCase): |
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.
These restart cases test that all of the appropriate data is stored in the databases. Trajectory parameters were previously not being saved before this PR.
assert_near_equal(sim_results.get_val('traj.rto.timeseries.states:r')[-1], 2016, | ||
tolerance=0.01) | ||
|
||
|
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.
The "default values" case is an experiment to play with setting all values via the add_state
, add_control
, set_time_options
, etc methods. When playing around with adding and removing phases, having the phase definition and the values setting in two parts of the file is a bit annoying. The downside of this method is that the values have to be set with their problem units, unlike using the set_val
method.
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.
This makes those methods more consistent with all the other openmdao methods too.
Summary
Added a balanced field length example consisting of five phases. This example uses notional Boeing 737 data from publicly available sources to model a low-fidelity propagation of the aircraft down the runway and into the initial climb.
The example propagates down the runway until some airspeed 'V1' which is the latest point at which a successful rejected takeoff can be performed in case of a single engine outage.
The objective of this problem is to find the minimum length runway such that:
This pull request is in process - documentation is pending but the PR is started to get some initial feedback on the implementation.
Related Issues
When developing this example we found that some default values for states, and time were not taking effect. This has been fixed.
We also found that trajectory parameters were not being saved in the simulation database recording. This has been fixed.
Status
Backwards incompatibilities
None
New Dependencies
None