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 sub-scenarios, 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 an MDA) or MDO sub-scenarios (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.

@startuml
Scenario -> Driver: solve
Driver -> "Optimization problem": get_objective_and_constraints()
Driver <- "Optimization problem": objective, constraints

loop Optimization convergence
    Driver -> "Objective function": call(x)
    "Objective function" -> "Generic process": execute(data)
    loop MDA convergence
        "Generic process" -> "Discipline1": execute(data)
        "Generic process" <- "Discipline1": outputs1
        "Generic process" -> "Discipline2": execute(data)
        "Generic process" <- "Discipline2": outputs2
    end
    "Objective function" <- "Generic process": objective_value
    Driver <- "Objective function": objective_value
    Driver -> "Objective function": gradient(x)
    "Objective function" -> "Generic process": linearize(data)
    "Generic process" -> "Discipline1": linearize(data)
    "Generic process" <- "Discipline1": jacobian1
    "Generic process" -> "Discipline2": linearize(data)
    "Generic process" <- "Discipline2": jacobian2
    "Generic process" <- "Generic process": coupled_derivatives()
    "Objective function" <- "Generic process": coupled_derivatives
    Driver <- "Objective function": objective_gradient
end

Scenario <- Driver: optimum

@enduml

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:

  • MDOFunction instances (for the objective function and the possible constraints) are generated by the BaseMDOFormulation. Depending on the formulation, constraints may be generated as well (e.g. consistency constraints in IDF).

  • DisciplineAdapterGenerator is a utility class that handles the MDOFunction generation for a given Discipline. It is a key class for the MDO formulations designer.

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.

@startuml
class BaseScenario {
}
class Discipline {
}
class BaseMDOFormulation {
}
class OptimizationProblem {
}
class DesignSpace {
}
class DisciplineAdapterGenerator {
}
class MDOFunction {
}
class BaseDriverLibrary {
}

Discipline <|- BaseScenario
BaseScenario "1" *-> "n" Discipline
BaseScenario "1" *-> "1" BaseMDOFormulation
BaseMDOFormulation "1" --> "n" OptimizationProblem
DisciplineAdapterGenerator "1" --> "n" MDOFunction
DisciplineAdapterGenerator "1" *-> "1" Discipline
BaseScenario "1" *-> "1" BaseDriverLibrary
OptimizationProblem "1" *-> "1" DesignSpace
OptimizationProblem "1" *-> "n" MDOFunction
BaseMDOFormulation "1" *-> "n" DisciplineAdapterGenerator
@end uml

@startuml
class Discipline {
}
class MDA {
}
class MDOChain {
}
class MDAJacobi {
}
class MDAGaussSeidel {
}
class MDAChain {
}

Discipline <|- MDA
MDA "1" *-> "1" Discipline
MDA <|- MDAJacobi
MDA <|- MDAGaussSeidel
Discipline <|- MDOChain
MDA <|- MDAChain
MDOChain "1" <-- "1" MDAChain
MDAChain "1" *-> "n" MDA
MDOChain "1" *-> "1" Discipline


@end uml

@startuml
class BaseScenario {
}
class BaseDriverLibrary {
}
class BaseDOELibrary {
}
class BaseOptimizationLibrary {
}
class MDOScenario {
}
class DOEScenario {
}

BaseDOELibrary -up|> BaseDriverLibrary
BaseOptimizationLibrary -up|> BaseDriverLibrary
BaseScenario "1" *-up> "1" BaseDriverLibrary
DOEScenario "1" *-> "1" BaseDOELibrary
MDOScenario "1" *-> "1" BaseOptimizationLibrary
MDOScenario -up|> BaseScenario
DOEScenario -up|> BaseScenario
@end uml

@startuml
class OptimizationProblem {
}
class DesignSpace {
}
class MDOFunction {
}
class Database {
}
class BaseMDOFormulation {
}

BaseMDOFormulation "1" --up> "1" OptimizationProblem
OptimizationProblem "1" *-up> "1" DesignSpace
OptimizationProblem "1" *-up> "n" MDOFunction
OptimizationProblem "1" *-> "1" Database
@end uml