Architecture principles

This page describes the key aspects of GEMSEO architecture. It describes the main concepts used to build MDO processes. Two scientific papers give details on the subject [GVGuenot+18], [GBOG19].

General description

GEMSEO is responsible for managing the MDO scenario, including the optimization problem, that includes the objective function, constraints, coupling variables, and design variables.

GEMSEO is independent of all disciplinary tools and thus can be used with any business case. Within the process, it executes the disciplines accordingly to the needs of the optimization algorithm or DOE, called driver. It is in charge of the of the optimization problem and links the mathematical methods to the simulation software.

It can be interfaced with multiple workflow engines, typically in charge of chaining elementary across multiple machines. GEMSEO triggers the execution of disciplines or chains of disciplines when requested by the driver.

The interfaces of GEMSEO to an MDO platform and simulation capabilities

GEMSEO must provide generic interfaces, so that it can be integrated within any MDO platform technology.

../_images/components_platform.png

The Formulations Engine within its environment

GEMSEO components interactions

GEMSEO is split into 3 main component layers:

GEMSEO architecture is modular. Many of its packages and classes are independent:

  • The Optimization framework, which connects solvers and helps to formulate optimization problems, can be used to solve user-defined optimization problem, without any process or MDO formulation. Here are some examples.

  • Many generic processes, such as the MDAs and chains, can be used to solve coupling problems without doing an MDO. Again, some examples are provided in the package.

  • The optimization results plots can be generated from optimization histories stored in HDF5 files, or by using the Python API to read external data. So you may draw the same plots from optimization data generated outside of GEMSEO.

The next figure shows the main components of GEMSEO within an MDO platform.

../_images/components_all.png

GEMSEO components

At process building step

When the scenario is instantiated by the user, typically in a script or by a platform, the process is built. Then the user can configure the overall process, before execution, by accessing and changing the objects attributes that define the process.

  1. At this stage, the scenario instantiates the MDO formulation according to the user’s choice.

  2. Then, the formulation possibly creates generic processes such as MDAs (for MDF), or MDO subscenarios, for bi-level formulations.

  3. Once this is performed, the MDO formulation creates an optimization problem.

  4. This optimization problem is defined by the objective function and constraints, that eventually points to the generic processes or directly to the disciplines (for IDF for instance).

The next figure shows the components interaction at this step.

../_images/components_build_process.png

Components interaction at the build step of the process

During process execution

During the process execution :

  1. A driver is instantiated, it can be either an optimization algorithm or a DOE algorithm.

  2. The driver solves the optimization problem that was created by the MDO formulation at the building step.

  3. To this aim, the driver calls the objective function and constraints.

  4. These functions point to the generic processes (that aim at solving a coupling problem for a MDA) or MDO subscenarios (for bi-level scenarios), in order to find an optimum.

  5. These calls trigger the generic process execution, which themselves execute the disciplines.

../_images/components_execute_process.png

Components interactions at execution of the process

The sequence diagram shows the data exchanges during the execution. Here the generic process may be a Multi Disciplinary Analyses in the case of MDF, which calls the disciplines. We represent only the objective function calls, since the constraints are handled in a similar way. The calls to the objective and its gradient are made within a loop, until convergence of the optimization algorithm (the driver). The scenario then retrieves the optimum from the driver.

During results analysis

After the execution, convergence plots of the optimization can be generated. In addition, design space analysis, sensitivity analysis and constraints plots can be generated. For a complete overview of GEMSEO post-processing capabilities, see How to deal with post-processing. This can be achieved either from disk data (a serialized optimization problem), or from in-memory data after execution.

The user triggers the plots generation from a post-processing factory, or via the scenario, which delegates the execution to the same factory. The main steps are:

  1. The post-processing factory loads an optimization problem from the disk, or in memory from a Scenario.

  2. The data is split into a design space data, which contains the design variables names, bounds and types,

  3. and a database of all data generated during execution, typically the objective function, constraints, their derivatives, and eventually algorithmic data.

  4. Once the data is available, the factory loads the appropriate plot generation class for the plots required by the user, and calls the plot generation method.

../_images/results_analysis.png

Components interactions during results analysis

Main classes

The high level classes that are key in the architecture are:

Two low-level classes at the core of GEMSEO are crucial for the understanding of its basic principles:

The present figures display the main classes of GEMSEO. They are simplified class diagrams ; only parts of the subclasses and methods are represented. The present documentation contains the full classes description in the different sections as well as the full API documentation.