[Proposal] Native DOE Integration for FAST-OAD

[enricostragiotti]

Design of Experiments (DOE) is a valuable tool in aeronautical engineering, enabling rapid exploration of an aircraft's design space. DOE allows engineers to compare design choices, assess the impact of new technologies, and evaluate sensitivity to various parameters. For these reasons, I believe it would be highly beneficial for FAST-OAD to support native DOE execution, both from configuration files and command-line interfaces, similarly to the current capabilities for MDA and MDO.

Main Features:

• Seamless DOE Execution: Integrate DOE launch directly from the configuration file, enabling a user experience consistent with MDA and MDO processes.
• Customizable Sampling: Allow users to define the sampling method for the design space (e.g., Latin Hypercube Sampling, full factorial, etc.).
• Parallelized Execution: Support parallel execution of multiple FAST-OAD instances locally and on HPC resources to facilitate fast evaluation of hundreds of configurations.
• Automatic File Organization: When initiating DOE, automatically generate subfolders for each run, containing all necessary files to locally relaunch MDA (i.e., configuration file, modified data file for the specific calculation ID, and mission files). A CSV file in the root directory will also record the input variables modified by the DOE for each run ID.

Nice-to-Have Features:

• Nested DOE Support: Enable nested DOEs for constructing multifidelity surrogate models.
• Support for Discrete and Categorical Variables: Although FAST-OAD currently may not support discrete variables, it would be useful to allow DOE configurations that include such variables—for instance, to evaluate design shifts from a T-tail to a conventional tail, or to test different numbers of engines.
• Linked Variable Variation: Allow specific variables to be modified in tandem (e.g., linking the fuel efficiency parameter k for both cruise and takeoff stages), ensuring variables change together rather than independently.
• Basic Post-Processing Tools: Provide users with basic post-processing options, including a CSV file of requested output variables, along with a scatter matrix (example: scatterplot matrix) and basic response surfaces.

Future Developments:

• DOE-Driven Optimization: Use DOE results to identify the set of possible starting design points for subsequent optimization processes.
• GUI for Result Analysis: A graphical user interface for result analysis could add significant value, ideally allowing users to build surrogate models, visualize contour plots, filter out configurations based on resutls, and conduct advanced sensitivity analyses with Sobol indices.

Expected User Inputs:

• DOE variable names
• Numerical bounds for each DOE variable, provided as absolute values or percentage variations relative to values in the data file
• Sampling algorithm selection -Number of samples
• Random seed value for reproducibility
• Maximum processors allowed for evaluation
• Output directory containing subfolders for each experiment run, along with a CSV summarizing modified input variables and an unique ID.

[enricostragiotti]

I add here a sample of what would the configuration file looks like:

# Input and output files
input_file: ./problem_inputs.xml
output_file: ./problem_outputs.xml

# Definition of problem driver assuming the OpenMDAO convention "import openmdao.api as om"
driver: om.ScipyOptimizeDriver(tol=1e-2, optimizer='COBYLA')

model:
  nonlinear_solver: om.NonlinearBlockGS(maxiter=100, atol=1e-2)
  linear_solver: om.DirectSolver()
  geometry:
    # An OpenMDAO component is identified by its "id"
    id: fastoad.geometry.legacy
    # ....
  performance:
    id: fastoad.performances.mission
    propulsion_id: fastoad.wrapper.propulsion.rubber_engine
    mission_file_path: ::sizing_mission
    out_file: ./flight_points.csv
    adjust_fuel: true
    is_sizing: true

design_of_experiments:
  - name: exploration_1
  # Multiple DOEs can be defined in the same configuration file. The name will 
  # be used to generate the subfolders of the calculations
    variables:
      # Description of the variables and the bounds used to create the DOE
      - name: data:geometry:wing:aspect_ratio
        lower: 9.0
        upper: 18.0
      - name: data:geometry:wing:MAC:at25percent:x
        # The bounds can be absolute or relative to a given value or to the value 
        # of the MDA (requires model definition in the configuration file)
        lower_perc: 20.0
        upper_perc: 20.0
        ref_value: evaluate
      - name: data:geometry:wing:sweep_25
        # We can mix percentage and absolute bounds
        lower_perc: 20.0
        upper: 26.0
        ref_value: 25.0
  - name: exploration_2
    variables:
      - name: tuning:propulsion:rubber_engine:SFC:k_cr
        lower: 0.8
        upper: 1.0
      - name: tuning:propulsion:rubber_engine:SFC:k_sl
        bounds_binding_to: tuning:propulsion:rubber_engine:SFC:k_cr
        # Variable can be bind together and share the same value in the DOE
    sampling:
    # Overwrite here the common settings (written later in the file)
      algorithm: FullFactorial
      n_samples: 20
  # Common settings (for all the DOEs in the file)
  sampling:
    algorithm: NestedLHS
    n_samples: 150
    seed_val: 12
    options:
      - nlevel=2
  computing:
    max_CPUs: 8
  output_folder: ./DOE

[rparello]

A few things that would be nice to have:

• a way to define inputs that are array into the DOE
• a way to have a model option as DOE inputs
• in accordance with the previous point, some inputs could be integer or even string to be chosen in a list in the case of option, not float
• the possibilty to use different point selection method for different variables; for example, one could be LMS and a second full factorial