Skip to content

Remote File-Based Optimization

Remote File-Based Optimization (RFSAO) enables the optimization problem to be driven by and executed in another environment than ADORE, for example an MDAO execution platform. This can be useful if you want to use analysis tools integrated in such a platform or if you are using file-based, remote communication to/from such tools. In ADORE, the RFSAO mechanism additionally allows you to define and execute the optimization problem without the need for writing any code.

Defining the Optimization Problem

The optimization problem is defined in the ADORE GUI, after having modeled the design space:

  1. On the "design problems" tab, create a new design problem.
  2. Configure the design problem if needed, then click "Start Remote Optimization". Note: this is only available, if the design problem has at least one design variable and at least one objective.
  3. Configure the optimization algorithm (see below).
  4. Configure the evaluation interface: XML, JSON, XML Node Factory Evaluator, or CPACS.
    1. For the XML NFE, you also need to provide the settings xpath.
  5. Click "Get optimization file": this gives you an .adoreopt file, which stores the model along with the optimizer configuration and optimization state.

Configuring the Optimization Algorithm

The following algorithms are available (refer to SBArchOpt for more details):

  • Design of Experiments (DoE): statically explores the design space, which is useful for an initial exploration and validation/testing. Settings:
    • Number of design points: as a rule-of-thumb, you need 5 to 10 times the amount of design variables for a good exploration (e.g. to build a surrogate model). For initial testing, only a few points are recommended.
  • NSGA-II: a multi-objective genetic algorithm, effective for cheap evaluation (in the order of seconds). Settings:
    • Population size: number of architectures in the population (rule-of-thumb: 5 times the number of design variables).
    • Generations: number of generations to run the algorithm for (10 to 20 usually gives a good estimate of the Pareto front already).
  • Bayesian Optimization (BO): a Surrogate-Based Optimization (SBO) algorithm that builds a model of the design space and uses that to find infill points to find the optimum. Needs fewer evaluations than NSGA-II, however retraining the surrogate model at each run takes time as well, so it should only be used if evaluation is expensive. Settings:
    • DoE size: initial DoE exploration (rule-of-thumb: 5 times the number of design variables).
    • Infill points: number of extra points to suggest for exploration.
    • Minimum Probability of Feasibility: PoF threshold, 50% works well; increase to make search more conservative w.r.t. constraints, decrease to make it more explorative.
    • PLS dimensions: dimensional reduction of the underlying surrogate model, reduces training/infill time at the cost of less accuracy.

Note: the optimization algorithm can be changed and/or reconfigured starting from previous evaluation results, by opening an .adoreopt file in the GUI. See Inspecting Optimization Results for more details.

Executing the Optimization Problem

With the .adoreopt file, you can now switch to the execution environment, and provide it as input there. The optimization step is performed by the AdoreOpt block, which performs a "tell-ask" step:

  1. It "tells" previous evaluation results to ADORE.
  2. It "asks" for a new architecture to evaluate.

Using this mechanism, control is effectively inverted from ADORE to the execution environment. Also, because at each step a new .adoreopt file is created, which stores the optimizer state, using an "intermediary" .adoreopt file when starting the workflow effectively resumes optimization from that state.

How to exactly use the RFSAO tell-ask mechanism depends on the execution environment of your choice, see the sections below.

For more details about the tell-ask mechanism and the state file, refer to Section 4.3 of "System Architecture Optimization".

Remote Component Environment (RCE)

For RCE, DLR's open-source MDAO execution platform, ADORE provides an integration of the AdoreOpt block and a workflow template to use for setting up RFSAO.

You can find the AdoreOpt integration instructions and workflow template in the evaluation materials under remote_file_based: ADORE Evaluation Docs (RFSAO)

Overview of the workflow template:

RCE Workflow Template

Other Platforms

Integration into other platforms is done by calling the RFSAO CLI script to perform the tell-ask step. Depending on how you have installed ADORE, the script is available as follows:

  • Installed as a Python library: adore_opt command (in the activated Python environment)
  • Installed as a standalone executable: adore_opt_cli.exe
>> adore_opt --help
usage: CLI for optimization of ADORE models [-h] [--csv_export_file CSV_EXPORT_FILE] [--debug] adore_opt_file adore_opt_out_file output_file input_file

positional arguments:
  adore_opt_file        File storing the ADORE optimization config and state (input)
  adore_opt_out_file    File storing the ADORE optimization config and state (output)
  output_file           File with the evaluation output (or parameter file if needed)
  input_file            Target location of the input file

optional arguments:
  -h, --help            show this help message and exit
  --csv_export_file CSV_EXPORT_FILE
                        CSV architecture export file
  --debug               Output debug info

Some pointers:

  • adore_opt_file and adore_opt_out_file are the input and output (respectively) .adoreopt files used/created by the tell-ask step.
  • output_file is the file containing evaluation outputs OR an initial file (first interation of the workflow):
    • For the XML and JSON evaluators, this can be anything, for example an empty file.
    • For the XML NFE and CPACS evaluators, this should be the base file containing the factory settings.
  • input_file is the target location of the file that is input to the evaluation, containing the serialized system architecture instance.
  • The AdoreOpt CLI is stateless: the .adoreopt file contains all the information for executing the optimization problem, including the optimizer state. Effectively this also provides restart/resume capabilities.

Inspecting Optimization Results

.adoreopt files can be opened in the ADORE GUI, which allows you to:

  • Inspect intermediary or final optimization results.
  • View and inspect the generated architecture instances.
  • Export the generated and evaluated architectures as CSV: on the "design problems" page, click the download icon in the "Architectures" column of the respective design problem.
  • Reconfigure the optimization problem (e.g. change optimizer or optimizer settings):
    • When creating a new .adoreopt file, it will continue from the previously evaluated architectures.
    • This can be used to implement an "incremental" approach to running the optimization, for example:
      • First run a very small DoE to test if evaluation works.
      • Then increase the DoE size to 5 times the number of design variables.
      • Finally run infill points using SBO/BO to find optimal designs.