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.
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.
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.
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.
At this stage, the scenario instantiates the MDO formulation according to the user’s choice.
The next figure shows the components interaction at this step.
During process execution¶
During the process execution :
The driver solves the optimization problem that was created by the MDO formulation at the building step.
To this aim, the driver calls the objective function and constraints.
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.
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:
The post-processing factory loads an optimization problem from the disk, or in memory from a Scenario.
The data is split into a design space data, which contains the design variables names, bounds and types,
and a database of all data generated during execution, typically the objective function, constraints, their derivatives, and eventually algorithmic data.
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.
The high level classes that are key in the architecture are:
MDOScenariobuilds the process from a set of inputs, several disciplines and a formulation. It is one of the main interface class for the MDO user. The
MDOScenariotriggers the overall optimization process when its
execute()method is called. Through this class, the user provides an initial solution, user constraints, and bounds on the design variables. The user may also generate visualization of the scenario execution, such as convergence plots of the algorithm (see Tutorial: How to solve a MDO problem).
DOEScenariobuilds the process from a set of inputs, several disciplines and a formulation. It is the second main interface class for the MDO user. The
DOEScenariotriggers the overall trade-off process when its
execute()method is called. Through this class, the user provides a design space, some outputs to monitor (objective and constraints) and a number of samples. The user may also generate visualization of the scenario execution, such as convergence plots of the algorithm . As the
DOEScenariomakes the link between all the following classes. It is mainly handled by the MDO integrator. Both
DOEScenarioinherit from the
Scenarioclass that defines common features (bounds, constraints, …).
MDODisciplinerepresents a wrapped simulation software program or a chain of wrapped software. It can either be a link to a discipline integrated within a workflow engine, or can be inherited to integrate a simulation software directly. Its inputs and outputs are represented in a Grammar (see
MDOFormulationdescribes the MDO formulation (e.g. MDF and IDF) used by the
Scenarioto generate the
OptimizationProblem. The MDO user or the MDO integrator may either provide the name of the formulation, or a class, or an instance, to the
DOEScenario) . The MDO formulations designer may create, implement, test or maintain MDO formulations with this class.
OptimizationProblemdescribes the mathematical functions of the optimization problem (objective function and constraints, along with the design variables. It is generated by the
MDOFormulation, and solved by the optimization algorithm. It has an internal database that stores the calls to its functions by the optimization algorithm to avoid duplicate computations. It can be stored on disk and analyzed a posteriori by post-processing available in GEMSEO.
Two low-level classes at the core of GEMSEO are crucial for the understanding of its basic principles:
MDOFunctioninstances (for the objective function and the possible constraints) are generated by the
MDOFormulation. Depending on the formulation, constraints may be generated as well (e.g. consistency constraints in IDF).
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.