OpenMDAO
Convert Options to Inputs
Desired capability or behavior.
There are a number of options that users will want to manipulate during the optimization.
For example: Aircraft.Wing.LOAD_PATH_SWEEP_DIST are actually functions of Aircraft.Wing.SWEEP and should change as sweep changes. However, Aircraft.Wing.LOAD_PATH_SWEEP_DIST is an option and thus is not allowed to change during the optimization. This value contributes as a secondary effect to wing weight calculations.
Is your feature request related to a problem? Please describe.
No response
Associated Bug Report
No response
In general would it be better for all options to be converted to inputs, just in case a user wants to run an optimization that varies one of those parameters? Why is it beneficial to have options at all?
Just spoke to @Kenneth-T-Moore and you're correct @xjjiang - we will need to keep all integers and booleans as options as they won't work with gradient based optimizer.
I have reviewed all of the options in MDAO components for FLOPS-based mass and have found no other variables I believe should be converted from options to inputs. Here is the list of distinct options across all the flops mass components:
| Variable | DataType | Notes |
|---|---|---|
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_PASSENGERS) | Integer | |
| add_aviary_option(self, Mission.Constraints.MAX_MACH) | Float | Constraint - not changed during optimization |
| add_aviary_option(self, Aircraft.Engine.NUM_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Propulsion.TOTAL_NUM_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Engine.REFERENCE_SLS_THRUST, units='lbf') | Float | If e.g. NPSS is used for propulsion in loop then this might need to be converted to an input? |
| add_aviary_option(self, Aircraft.CrewPayload.NUM_FLIGHT_CREW) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.BAGGAGE_MASS_PER_PASSENGER, units='lbm') | Float | would this ever change mid optimization? |
| add_aviary_option(self, Aircraft.CrewPayload.MASS_PER_PASSENGER, units='lbm') | Float | would this ever change? |
| add_aviary_option(self, Aircraft.CrewPayload.NUM_FLIGHT_ATTENDANTS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.NUM_GALLEY_CREW) | Integer | |
| add_aviary_option(self, Aircraft.Fuselage.NUM_FUSELAGES) | Integer | |
| add_aviary_option(self, Aircraft.Engine.ADDITIONAL_MASS_FRACTION) | Float | Might change if used for accounting for some miscellaneous engine/propulsion mass in loop. |
| add_aviary_option(self, Aircraft.Engine.REFERENCE_MASS, units='lbm') | Float | might also change if e.g. NPSS in loop |
| add_aviary_option(self, Aircraft.Engine.SCALE_MASS) | Boolean | |
| add_aviary_option(self, Aircraft.Fins.NUM_FINS) | Integer | |
| add_aviary_option(self, Aircraft.Fuel.NUM_TANKS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_BUSINESS_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_FIRST_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_TOURIST_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.Fuselage.MILITARY_CARGO_FLOOR) | Boolean | |
| add_aviary_option(self, Aircraft.Propulsion.TOTAL_NUM_FUSELAGE_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Propulsion.TOTAL_NUM_WING_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Engine.NUM_WING_ENGINES) | Integer | (is this the same as above?) |
| add_aviary_option(self, Aircraft.Design.USE_ALT_MASS) | Boolean | |
| add_aviary_option(self, Aircraft.Engine.NUM_ENGINES) | Integer | (is this the same as above?) |
| add_aviary_option(self, Aircraft.VerticalTail.NUM_TAILS) | Integer | |
| add_aviary_option(self, Aircraft.Wing.INPUT_STATION_DIST) | Float Vector | Vector of input stations as fraction of semispan. Could change if trying to do a wing planform optimization...? Might not play nicely with gradients...? |
| add_aviary_option(self, Aircraft.Wing.LOAD_DISTRIBUTION_CONTROL) | Integer | Tertiary options 1,2,3 |
| add_aviary_option(self, Aircraft.Wing.NUM_INTEGRATION_STATIONS) | Integer | |
| add_aviary_option(self, Aircraft.Wing.DETAILED_WING) | Boolean |
Table of unique options for all Flops-Based Geometry components:
| Variable | DataType | Notes |
|---|---|---|
| add_aviary_option(self, Aircraft.Wing.INPUT_STATION_DIST) | Float | Vector of floats - this might change if doing planform optimization? |
| add_aviary_option(self, Settings.VERBOSITY) | Integer | |
| add_aviary_option(self, Aircraft.Engine.NUM_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Wing.SPAN_EFFICIENCY_REDUCTION) | Boolean | |
| add_aviary_option(self, Aircraft.Fuselage.NUM_FUSELAGES) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_FIRST_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_TOURIST_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_SEATS_ABREAST_FIRST) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_SEATS_ABREAST_TOURIST) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.SEAT_PITCH_FIRST) | Float | These could be inputs, but optimizer will likely minimize these parameters and so not really worth adding into the optimization - obviously cramming people into smaller space will be better for aircraft performance if you allow the optimizer to do it. |
| add_aviary_option(self, Aircraft.CrewPayload.Design.SEAT_PITCH_TOURIST) | Float | as above |
| add_aviary_option(self, Aircraft.BWB.MAX_NUM_BAYS) | Integer | Should this be a constraint? |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_BUSINESS_CLASS) | Integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.NUM_SEATS_ABREAST_BUSINESS) | integer | |
| add_aviary_option(self, Aircraft.CrewPayload.Design.SEAT_PITCH_BUSINESS) | Float | As for seat pitch for tourist and first |
| add_aviary_option(self, Aircraft.Fuselage.SIMPLE_LAYOUT) | Boolean | |
| add_aviary_option(self, Aircraft.Design.TYPE) | Enum | |
| add_aviary_option(self, Aircraft.BWB.DETAILED_WING_PROVIDED) | Boolean | |
| add_aviary_option(self, Aircraft.Wing.NUM_INTEGRATION_STATIONS) | Integer | |
| add_aviary_option(self, Aircraft.Propulsion.TOTAL_NUM_FUSELAGE_ENGINES) | Integer |
- Interestingly I noticed that the DetailedCabinLayout function only contains seat information for tourist and first, whereas BWBDetailedCabinLayout contains information for tourist, business and first. We should check if this is correct or if there is missing FLOPS functionality here. @xjjiang - I think you've looked at the fortran code for the BWB recently - do you happen to know if business information should be used by the conventional detailedcabinlayout function?
Table of unique options for Flops-Based Aerodynamics:
| Variable | DataType | Notes |
|---|---|---|
| add_aviary_option(self, Aircraft.Wing.AIRFOIL_TECHNOLOGY) | Float | Value between 1 and 2 doesn't make sense to change this during optimization as this would affect the internal aero performance. User would be better to provide tabular aero or something to cover special conditions where this parameter would need to update during the mission. |
| add_aviary_option(self, Mission.Constraints.MAX_MACH) | Float | Constraint doesn't change during optimization |
| add_aviary_option(self, Aircraft.Engine.NUM_ENGINES) | Integer | |
| add_aviary_option(self, Aircraft.Wing.SPAN_EFFICIENCY_REDUCTION) | Boolean | |
| add_aviary_option(self, Aircraft.Fuselage.NUM_FUSELAGES) | Integer | |
| add_aviary_option(self, Aircraft.VerticalTail.NUM_TAILS) | Integer | |
| add_aviary_option(self, Aircraft.LandingGear.DRAG_COEFFICIENT) | Float | If user was doing some sort of custom landing gear optimization then potentially this could change during the optimization. For flops based takeoff aero I think it is fine to leave this as an option |
| self.options.declare('num_nodes', types=int) | Integer | |
| self.options.declare('gamma', default=1.4, desc='Ratio of specific heats for air.') | Float | Atmosphere won't change during optimization |
I have also checked Atmosphere and Energy subsystems and do not think any of those options need changing.
motor_mission and motor_premission add the whole of aviary_values as an option to the mdao component. I don't think it gets used in motor_mission so perhaps we can remove it...
motor_mission and motor_premission add the whole of aviary_values as an option to the mdao component. I don't think it gets used in motor_mission so perhaps we can remove it...
It looks like we are using aviary_values for Aircraft.Engine.RPM_DESIGN in motor_premission.py. But I agree it doesn't look like we use aviary_values at all in motor_mission.py