.. DO NOT EDIT. .. THIS FILE WAS AUTOMATICALLY GENERATED BY SPHINX-GALLERY. .. TO MAKE CHANGES, EDIT THE SOURCE PYTHON FILE: .. "examples/mdo/plot_gemseo_in_10_minutes.py" .. LINE NUMBERS ARE GIVEN BELOW. .. only:: html .. note:: :class: sphx-glr-download-link-note Click :ref:`here ` to download the full example code .. rst-class:: sphx-glr-example-title .. _sphx_glr_examples_mdo_plot_gemseo_in_10_minutes.py: |g| in 10 minutes ============================= .. _gemseo_10min: .. GENERATED FROM PYTHON SOURCE LINES 27-38 Introduction ------------ This is a short introduction to |g|, geared mainly for new users. In this example, we will set up a simple Multi-disciplinary Design Optimization (:term:`MDO`) problem based on a simple analytic problem. Imports ------- First, we will import all the classes and functions needed for the tutorials. .. GENERATED FROM PYTHON SOURCE LINES 39-52 .. code-block:: default from __future__ import annotations from math import exp from gemseo.api import configure_logger from gemseo.api import create_design_space from gemseo.api import create_discipline from gemseo.api import create_scenario from gemseo.api import generate_n2_plot from matplotlib import pyplot as plt from numpy import array from numpy import ones .. GENERATED FROM PYTHON SOURCE LINES 53-58 These imports are needed to compute mathematical expressions and to instantiate NumPy arrays. NumPy arrays are used to store numerical data in |g| at a low level. If you are not comfortable using NumPy, please have a look at the `Numpy Quickstart tutorial `_. .. GENERATED FROM PYTHON SOURCE LINES 60-62 Here, we configure the |g| logger in order to get information of the process as it is executed. .. GENERATED FROM PYTHON SOURCE LINES 62-65 .. code-block:: default configure_logger() .. rst-class:: sphx-glr-script-out .. code-block:: none .. GENERATED FROM PYTHON SOURCE LINES 66-81 A simple MDO test case: the Sellar Problem ------------------------------------------ We will consider in this example the Sellar's problem: .. include:: /tutorials/_description/sellar_problem_definition.inc Definition of the disciplines using Python functions ---------------------------------------------------- The Sellar's problem is composed of two :term:`disciplines ` and an :term:`objective function`. As they are expressed analytically, it is possible to write them as simple Python functions which take as parameters the :term:`design variables` and the :term:`coupling variables`. The returned values may be the outputs of a discipline, the values of the :term:`constraints` or the value of the objective function. Their definitions read: .. GENERATED FROM PYTHON SOURCE LINES 82-104 .. code-block:: default def f_sellar_system(x_local=1.0, x_shared_2=3.0, y_1=1.0, y_2=1.0): """Objective function.""" obj = x_local**2 + x_shared_2 + y_1**2 + exp(-y_2) c_1 = 3.16 - y_1**2 c_2 = y_2 - 24.0 return obj, c_1, c_2 def f_sellar_1(x_local=1.0, y_2=1.0, x_shared_1=1.0, x_shared_2=3.0): """Function for discipline 1.""" y_1 = (x_shared_1**2 + x_shared_2 + x_local - 0.2 * y_2) ** 0.5 return y_1 def f_sellar_2(y_1=1.0, x_shared_1=1.0, x_shared_2=3.0): """Function for discipline 2.""" y_2 = abs(y_1) + x_shared_1 + x_shared_2 return y_2 .. GENERATED FROM PYTHON SOURCE LINES 105-113 These Python functions can be easily converted into |g| :class:`.MDODiscipline` objects by using the :class:`.AutoPyDiscipline` discipline. It enables the automatic wrapping of a Python function into a |g| :class:`.MDODiscipline` by only passing a reference to the function to be wrapped. |g| handles the wrapping and the grammar creation under the hood. The :class:`.AutoPyDiscipline` discipline can be instantiated using the :func:`.create_discipline` function from the |g| :term:`API`: .. GENERATED FROM PYTHON SOURCE LINES 113-120 .. code-block:: default disc_sellar_system = create_discipline("AutoPyDiscipline", py_func=f_sellar_system) disc_sellar_1 = create_discipline("AutoPyDiscipline", py_func=f_sellar_1) disc_sellar_2 = create_discipline("AutoPyDiscipline", py_func=f_sellar_2) .. GENERATED FROM PYTHON SOURCE LINES 121-126 Note that it is possible to define the Sellar disciplines by subclassing the :class:`.MDODiscipline` class and implementing the constuctor and the _run method by hand. Although it would take more time, it may also provide more flexibility and more options. This method is illustrated in the :ref:`Sellar from scratch tutorial `. .. GENERATED FROM PYTHON SOURCE LINES 128-130 We then create a list of disciplines, which will be used later to create an :class:`.MDOScenario`: .. GENERATED FROM PYTHON SOURCE LINES 130-132 .. code-block:: default disciplines = [disc_sellar_system, disc_sellar_1, disc_sellar_2] .. GENERATED FROM PYTHON SOURCE LINES 133-136 We can quickly access the most relevant information of any discipline (name, inputs, and outputs) with Python's ``print()`` function. Moreover, we can get the default input values of a discipline with the attribute :attr:`.MDODiscipline.default_inputs` .. GENERATED FROM PYTHON SOURCE LINES 136-139 .. code-block:: default print(disc_sellar_1) print(f"Default inputs: {disc_sellar_1.default_inputs}") .. rst-class:: sphx-glr-script-out .. code-block:: none f_sellar_1 Default inputs: {'x_local': array([1.]), 'y_2': array([1.]), 'x_shared_1': array([1.]), 'x_shared_2': array([3.])} .. GENERATED FROM PYTHON SOURCE LINES 140-144 You may also be interested in plotting the couplings of your disciplines. A quick way of getting this information is the API function :func:`.generate_n2_plot`. A much more detailed explanation of coupling visualization is available :ref:`here `. .. GENERATED FROM PYTHON SOURCE LINES 144-146 .. code-block:: default generate_n2_plot(disciplines, save=False, show=True) .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_001.png :alt: plot gemseo in 10 minutes :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_001.png :class: sphx-glr-single-img .. GENERATED FROM PYTHON SOURCE LINES 147-154 .. note:: For the sake of clarity, these disciplines are overly simple. Yet, |g| enables the definition of much more complex disciplines, such as wrapping complex :term:`COTS`. Check out the other :ref:`tutorials ` and our :ref:`publications list ` for more information. .. GENERATED FROM PYTHON SOURCE LINES 156-161 Definition of the design space ------------------------------ In order to define :class:`.MDOScenario`, a :term:`design space` has to be defined by creating a :class:`.DesignSpace` object. The design space definition reads: .. GENERATED FROM PYTHON SOURCE LINES 161-170 .. code-block:: default design_space = create_design_space() design_space.add_variable("x_local", 1, l_b=0.0, u_b=10.0, value=ones(1)) design_space.add_variable("x_shared_1", 1, l_b=-10, u_b=10.0, value=array([4.0])) design_space.add_variable("x_shared_2", 1, l_b=0.0, u_b=10.0, value=array([3.0])) design_space.add_variable("y_1", 1, l_b=-100.0, u_b=100.0, value=ones(1)) design_space.add_variable("y_2", 1, l_b=-100.0, u_b=100.0, value=ones(1)) print(design_space) .. rst-class:: sphx-glr-script-out .. code-block:: none Design space: +------------+-------------+-------+-------------+-------+ | name | lower_bound | value | upper_bound | type | +------------+-------------+-------+-------------+-------+ | x_local | 0 | 1 | 10 | float | | x_shared_1 | -10 | 4 | 10 | float | | x_shared_2 | 0 | 3 | 10 | float | | y_1 | -100 | 1 | 100 | float | | y_2 | -100 | 1 | 100 | float | +------------+-------------+-------+-------------+-------+ .. GENERATED FROM PYTHON SOURCE LINES 171-179 Definition of the MDO scenario ------------------------------ Once the disciplines and the design space have been defined, we can create our MDO scenario by using the :func:`.create_scenario` API call. In this simple example, we are using a Multiple Disciplinary Feasible (:term:`MDF`) strategy. The Multiple Disciplinary Analyses (:term:`MDA`) are carried out using the Gauss-Seidel method. The scenario definition reads: .. GENERATED FROM PYTHON SOURCE LINES 179-188 .. code-block:: default scenario = create_scenario( disciplines, formulation="MDF", inner_mda_name="MDAGaussSeidel", objective_name="obj", design_space=design_space, ) .. GENERATED FROM PYTHON SOURCE LINES 189-213 It can be noted that neither a :term:`workflow ` nor a :term:`dataflow ` has been defined. By design, there is no need to explicitly define the workflow and the dataflow in |g|: - the workflow is determined from the MDO formulation used. - the dataflow is determined from the variable names used in the disciplines. Then, it is of uttermost importance to be consistent while choosing and using the variable names in the disciplines. .. warning:: As the workflow and the dataflow are implicitly determined by |g|, set-up errors may easily occur. Although it is not performed in this example, it is strongly advised to - check the interfaces between the several disciplines using an N2 diagram, - check the MDO process using an XDSM representation Setting the constraints ----------------------- Most of the MDO problems are under :term:`constraints`. In our problem, we have two inequality constraints, and their declaration reads: .. GENERATED FROM PYTHON SOURCE LINES 213-217 .. code-block:: default scenario.add_constraint("c_1", "ineq") scenario.add_constraint("c_2", "ineq") .. GENERATED FROM PYTHON SOURCE LINES 218-225 Execution of the scenario ------------------------- The scenario is now complete and ready to be executed. When running the optimization process, the user can choose the optimization algorithm and the maximum number of iterations to perform. The execution of the scenario reads: .. GENERATED FROM PYTHON SOURCE LINES 225-228 .. code-block:: default scenario.execute(input_data={"max_iter": 10, "algo": "SLSQP"}) .. rst-class:: sphx-glr-script-out .. code-block:: none INFO - 14:47:23: INFO - 14:47:23: *** Start MDOScenario execution *** INFO - 14:47:23: MDOScenario INFO - 14:47:23: Disciplines: f_sellar_1 f_sellar_2 f_sellar_system INFO - 14:47:23: MDO formulation: MDF INFO - 14:47:23: Optimization problem: INFO - 14:47:23: minimize obj(x_local, x_shared_1, x_shared_2) INFO - 14:47:23: with respect to x_local, x_shared_1, x_shared_2 INFO - 14:47:23: subject to constraints: INFO - 14:47:23: c_1(x_local, x_shared_1, x_shared_2) <= 0.0 INFO - 14:47:23: c_2(x_local, x_shared_1, x_shared_2) <= 0.0 INFO - 14:47:23: over the design space: INFO - 14:47:23: +------------+-------------+-------+-------------+-------+ INFO - 14:47:23: | name | lower_bound | value | upper_bound | type | INFO - 14:47:23: +------------+-------------+-------+-------------+-------+ INFO - 14:47:23: | x_local | 0 | 1 | 10 | float | INFO - 14:47:23: | x_shared_1 | -10 | 4 | 10 | float | INFO - 14:47:23: | x_shared_2 | 0 | 3 | 10 | float | INFO - 14:47:23: +------------+-------------+-------+-------------+-------+ INFO - 14:47:23: Solving optimization problem with algorithm SLSQP: INFO - 14:47:23: ... 0%| | 0/10 [00:00`. .. GENERATED FROM PYTHON SOURCE LINES 247-252 .. code-block:: default scenario.post_process("OptHistoryView", save=False, show=False) # Workaround for HTML rendering, instead of ``show=True`` plt.show() .. rst-class:: sphx-glr-horizontal * .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_002.png :alt: Evolution of the optimization variables :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_002.png :class: sphx-glr-multi-img * .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_003.png :alt: Evolution of the objective value :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_003.png :class: sphx-glr-multi-img * .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_004.png :alt: Distance to the optimum :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_004.png :class: sphx-glr-multi-img * .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_005.png :alt: Hessian diagonal approximation :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_005.png :class: sphx-glr-multi-img * .. image-sg:: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_006.png :alt: Evolution of the inequality constraints :srcset: /examples/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_006.png :class: sphx-glr-multi-img .. GENERATED FROM PYTHON SOURCE LINES 253-258 .. note:: Such post-processings can be exported in PDF format, by setting :code:`save` to :code:`True` and potentially additional settings (see the :meth:`.Scenario.post_process` options). .. GENERATED FROM PYTHON SOURCE LINES 260-267 Exporting the problem data. --------------------------- After the execution of the scenario, you may want to export your data to use it elsewhere. The :meth:`.Scenario.export_to_dataset` will allow you to export your results to a :class:`.Dataset`, the basic |g| class to store data. From a dataset, you can even obtain a Pandas dataframe with its method :meth:`~.Dataset.export_to_dataframe`: .. GENERATED FROM PYTHON SOURCE LINES 267-270 .. code-block:: default dataset = scenario.export_to_dataset("a_name_for_my_dataset") dataframe = dataset.export_to_dataframe() .. GENERATED FROM PYTHON SOURCE LINES 271-277 What's next? ------------ You have completed a short introduction to |g|. You can now look at the :ref:`tutorials ` which exhibit more complex use-cases. You can also have a look at the documentation to discover the several features and options of |g|. .. rst-class:: sphx-glr-timing **Total running time of the script:** ( 0 minutes 1.681 seconds) .. _sphx_glr_download_examples_mdo_plot_gemseo_in_10_minutes.py: .. only:: html .. container:: sphx-glr-footer sphx-glr-footer-example .. container:: sphx-glr-download sphx-glr-download-python :download:`Download Python source code: plot_gemseo_in_10_minutes.py ` .. container:: sphx-glr-download sphx-glr-download-jupyter :download:`Download Jupyter notebook: plot_gemseo_in_10_minutes.ipynb ` .. only:: html .. rst-class:: sphx-glr-signature `Gallery generated by Sphinx-Gallery `_