Setting values in mission file

Any parameter value in the mission file can be provided in several ways:

hard-coded value and unit

The standard way is to set the parameter as value, with or without unit.

Note

If no unit is provided while parameter needs one, SI units will be assumed.

Provided units have to match OpenMDAO convention.

Examples:

altitude:
    value: 10.
    unit: km
altitude:
    value: 10000.   # equivalent to previous one (10km), because SI units are assumed
mach:
    value: 0.8
engine_setting:
    value: takeoff   # some parameters expect a string value

hard-coded value with no unit

When no unit is provided, the value can be set directly. As for hard-coded value and unit, if the concerned parameter is not dimensionless, SI units will be assumed.

Example:

mach: 0.8                   # no unit
altitude: 10000.            # == 10 km
engine_setting: takeoff     # string value

OpenMDAO variable

It is possible to provide a variable name instead of a hard-coded value. Then the value and unit will be set by some FAST-OAD module, or by the input file.

Example:

altitude: data:dummy_category:some_altitude

Contextual OpenMDAO variable

It is also possible to provide only a suffix for the variable name. Then the complete variable name will be decided by the hierarchy the defined parameter belongs to. The associated variable name will be data:mission:<mission_name>:<route_name>:<phase_name>:<suffix>.

It is useful when defining a route or a phase that will be used in several missions (see Mission file).

Note

• <route_name> and <phase_name> will be used only when applicable (see examples below).

• A contextual variable can be defined in a segment, but the variable will still be “associated” only to the phase.

A basic contextual variable is identified by a single tilde (~). In such case, <suffix> is the parameter name.

A generic contextual variable is preceded by a tilde. In such case, <suffix> is the name provided as value (without the tilde).

Example 1 : generic contextual variable in a route

routes:
  route_A:
    range: ~distance   # "distance" will be the used variable name
    parts:
      - ...

missions:
  mission_1:
    parts:
      - ...
      - route: route_A
      - ...
  mission_2:
    parts:
      - ...
      - route: route_A
      - ...

route_A contains the parameter range where a contextual variable name is affected. route_A is used as a step by both mission_1 and mission_2.

Then the mission computation has among its inputs:

• data:mission:mission_1:route_A:distance

• data:mission:mission_2:route_A:distance

Example 2 : basic contextual variable in a flight phase

phases:
  phase_a:
    thrust_rate: ~    # "thrust_rate" will be the used variable name

routes:
  route_A:
    range: ...
    parts:
      - phase_a
      - ...

missions:
  mission_1:
    parts:
      - ...
      - route: route_A
      - ...
  mission_2:
    parts:
      - ...
      - phase: phase_a
      - ...

phase_a contains the parameter thrust_rate where a contextual variable name is affected. phase_a is a used as a step by route_A, that is used as a step by mission_1. phase_a is also used as a step directly by mission_2.

Then the mission computation has among its inputs:

• data:mission:mission_1:route_A:phase_a:thrust_rate

• data:mission:mission_2:phase_a:thrust_rate