.. 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

        :ref:`Go to the end <sphx_glr_download_examples_mdo_plot_gemseo_in_10_minutes.py>`
        to download the full example code

.. rst-class:: sphx-glr-example-title

.. _sphx_glr_examples_mdo_plot_gemseo_in_10_minutes.py:


GEMSEO in 10 minutes
====================

.. 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:: Python

    from __future__ import annotations

    from math import exp

    from numpy import array
    from numpy import ones

    from gemseo import configure_logger
    from gemseo import create_design_space
    from gemseo import create_discipline
    from gemseo import create_scenario
    from gemseo import generate_n2_plot








.. 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
<https://numpy.org/doc/stable/user/quickstart.html>`_.

.. 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:: Python


    configure_logger()





.. rst-class:: sphx-glr-script-out

 .. code-block:: none


    <RootLogger root (INFO)>



.. 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:: /problems/sellar_problem_definition.inc

Definition of the disciplines using Python functions
----------------------------------------------------
The Sellar's problem is composed of two :term:`disciplines <discipline>` 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:: Python



    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:: Python


    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)





.. rst-class:: sphx-glr-script-out

 .. code-block:: none

     WARNING - 13:53:29: Discipline f_sellar_system: py_func has inconsistent type hints: either both the signature arguments and the return values shall have type hints or none. The grammars will not use the type hints at all.
     WARNING - 13:53:29: Discipline f_sellar_1: py_func has inconsistent type hints: either both the signature arguments and the return values shall have type hints or none. The grammars will not use the type hints at all.
     WARNING - 13:53:29: Discipline f_sellar_2: py_func has inconsistent type hints: either both the signature arguments and the return values shall have type hints or none. The grammars will not use the type hints at all.




.. 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 <sellar_from_scratch>`.

.. 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:: Python

    disciplines = [disc_sellar_system, disc_sellar_1, disc_sellar_2]








.. GENERATED FROM PYTHON SOURCE LINES 133-135

We can quickly access the most relevant information of any discipline (name, inputs,
and outputs) with their string representations:

.. GENERATED FROM PYTHON SOURCE LINES 135-137

.. code-block:: Python

    disc_sellar_1






.. raw:: html

    <div class="output_subarea output_html rendered_html output_result">
    <div style='background-color: #fafae2; padding: 10px;'>f_sellar_1<br/><ul><li>Inputs: x_local, x_shared_1, x_shared_2, y_2</li><li>Outputs: y_1</li></ul></div>
    </div>
    <br />
    <br />

.. GENERATED FROM PYTHON SOURCE LINES 138-141

Moreover,
we can get the default input values of a discipline
with the attribute :attr:`.MDODiscipline.default_inputs`:

.. GENERATED FROM PYTHON SOURCE LINES 141-143

.. code-block:: Python

    disc_sellar_1.default_inputs





.. rst-class:: sphx-glr-script-out

 .. code-block:: none


    {'x_shared_1': array([1.]), 'y_2': array([1.]), 'x_local': array([1.]), 'x_shared_2': array([3.])}



.. GENERATED FROM PYTHON SOURCE LINES 144-148

You may also be interested in plotting the couplings of your disciplines.
A quick way of getting this information is the high-level function
:func:`.generate_n2_plot`. A much more detailed explanation of coupling
visualization is available :ref:`here <coupling_visualization>`.

.. GENERATED FROM PYTHON SOURCE LINES 148-150

.. code-block:: Python

    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 151-158

.. 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 <tutorials_sg>` and
   our :ref:`publications list <references>` for more information.

.. GENERATED FROM PYTHON SOURCE LINES 160-165

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 165-174

.. code-block:: Python


    design_space = create_design_space()
    design_space.add_variable("x_local", l_b=0.0, u_b=10.0, value=ones(1))
    design_space.add_variable("x_shared_1", l_b=-10, u_b=10.0, value=array([4.0]))
    design_space.add_variable("x_shared_2", l_b=0.0, u_b=10.0, value=array([3.0]))
    design_space.add_variable("y_1", l_b=-100.0, u_b=100.0, value=ones(1))
    design_space.add_variable("y_2", l_b=-100.0, u_b=100.0, value=ones(1))
    design_space






.. raw:: html

    <div class="output_subarea output_html rendered_html output_result">
    <div style='background-color: #fafae2; padding: 10px;'>Design space:<br/><table>
        <tr>
            <th style='text-align: left;'>Name</th>
            <th style='text-align: left;'>Lower bound</th>
            <th style='text-align: left;'>Value</th>
            <th style='text-align: left;'>Upper bound</th>
            <th style='text-align: left;'>Type</th>
        </tr>
        <tr>
            <td>x_local</td>
            <td>0</td>
            <td>1</td>
            <td>10</td>
            <td>float</td>
        </tr>
        <tr>
            <td>x_shared_1</td>
            <td>-10</td>
            <td>4</td>
            <td>10</td>
            <td>float</td>
        </tr>
        <tr>
            <td>x_shared_2</td>
            <td>0</td>
            <td>3</td>
            <td>10</td>
            <td>float</td>
        </tr>
        <tr>
            <td>y_1</td>
            <td>-100</td>
            <td>1</td>
            <td>100</td>
            <td>float</td>
        </tr>
        <tr>
            <td>y_2</td>
            <td>-100</td>
            <td>1</td>
            <td>100</td>
            <td>float</td>
        </tr>
    </table></div>
    </div>
    <br />
    <br />

.. GENERATED FROM PYTHON SOURCE LINES 175-184

Definition of the MDO scenario
------------------------------
Once the disciplines and the design space have been defined,
we can create our MDO scenario
by using the high-level function :func:`.create_scenario`.
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 184-193

.. code-block:: Python


    scenario = create_scenario(
        disciplines,
        "MDF",
        "obj",
        design_space,
        inner_mda_name="MDAGaussSeidel",
    )








.. GENERATED FROM PYTHON SOURCE LINES 194-218

It can be noted that neither a :term:`workflow <work flow>`
nor a :term:`dataflow <data flow>` 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 218-222

.. code-block:: Python


    scenario.add_constraint("c_1", constraint_type="ineq")
    scenario.add_constraint("c_2", constraint_type="ineq")








.. GENERATED FROM PYTHON SOURCE LINES 223-230

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 230-233

.. code-block:: Python


    scenario.execute({"max_iter": 10, "algo": "SLSQP"})





.. rst-class:: sphx-glr-script-out

 .. code-block:: none

        INFO - 13:53:30:  
        INFO - 13:53:30: *** Start MDOScenario execution ***
        INFO - 13:53:30: MDOScenario
        INFO - 13:53:30:    Disciplines: f_sellar_1 f_sellar_2 f_sellar_system
        INFO - 13:53:30:    MDO formulation: MDF
        INFO - 13:53:30: Optimization problem:
        INFO - 13:53:30:    minimize obj(x_local, x_shared_1, x_shared_2)
        INFO - 13:53:30:    with respect to x_local, x_shared_1, x_shared_2
        INFO - 13:53:30:    subject to constraints:
        INFO - 13:53:30:       c_1(x_local, x_shared_1, x_shared_2) <= 0.0
        INFO - 13:53:30:       c_2(x_local, x_shared_1, x_shared_2) <= 0.0
        INFO - 13:53:30:    over the design space:
        INFO - 13:53:30:       +------------+-------------+-------+-------------+-------+
        INFO - 13:53:30:       | Name       | Lower bound | Value | Upper bound | Type  |
        INFO - 13:53:30:       +------------+-------------+-------+-------------+-------+
        INFO - 13:53:30:       | x_local    |      0      |   1   |      10     | float |
        INFO - 13:53:30:       | x_shared_1 |     -10     |   4   |      10     | float |
        INFO - 13:53:30:       | x_shared_2 |      0      |   3   |      10     | float |
        INFO - 13:53:30:       +------------+-------------+-------+-------------+-------+
        INFO - 13:53:30: Solving optimization problem with algorithm SLSQP:
        INFO - 13:53:30:     10%|█         | 1/10 [00:00<00:00, 37.96 it/sec, obj=21.8]
        INFO - 13:53:30:     20%|██        | 2/10 [00:00<00:00, 27.43 it/sec, obj=5.39]
        INFO - 13:53:30:     30%|███       | 3/10 [00:00<00:00, 25.96 it/sec, obj=3.41]
        INFO - 13:53:30:     40%|████      | 4/10 [00:00<00:00, 25.14 it/sec, obj=3.19]
        INFO - 13:53:30:     50%|█████     | 5/10 [00:00<00:00, 24.67 it/sec, obj=3.18]
        INFO - 13:53:30:     60%|██████    | 6/10 [00:00<00:00, 24.42 it/sec, obj=3.18]
        INFO - 13:53:30: Optimization result:
        INFO - 13:53:30:    Optimizer info:
        INFO - 13:53:30:       Status: 8
        INFO - 13:53:30:       Message: Positive directional derivative for linesearch
        INFO - 13:53:30:       Number of calls to the objective function by the optimizer: 7
        INFO - 13:53:30:    Solution:
        INFO - 13:53:30:       The solution is feasible.
        INFO - 13:53:30:       Objective: 3.183393951747747
        INFO - 13:53:30:       Standardized constraints:
        INFO - 13:53:30:          c_1 = 4.196643033083092e-12
        INFO - 13:53:30:          c_2 = -20.244722237800833
        INFO - 13:53:30:       Design space:
        INFO - 13:53:30:          +------------+-------------+-----------------------+-------------+-------+
        INFO - 13:53:30:          | Name       | Lower bound |         Value         | Upper bound | Type  |
        INFO - 13:53:30:          +------------+-------------+-----------------------+-------------+-------+
        INFO - 13:53:30:          | x_local    |      0      |           0           |      10     | float |
        INFO - 13:53:30:          | x_shared_1 |     -10     |   1.977638878736485   |      10     | float |
        INFO - 13:53:30:          | x_shared_2 |      0      | 7.449086152527647e-13 |      10     | float |
        INFO - 13:53:30:          +------------+-------------+-----------------------+-------------+-------+
        INFO - 13:53:30: *** End MDOScenario execution (time: 0:00:00.298057) ***

    {'max_iter': 10, 'algo': 'SLSQP'}



.. GENERATED FROM PYTHON SOURCE LINES 234-242

The scenario converged after 7 iterations.
Useful information can be found in the standard output, as seen above.

.. note::

   |g| provides the user with a lot of optimization algorithms and
   options. An exhaustive list of the algorithms available in |g| can be
   found in the :ref:`gen_opt_algos` section.

.. GENERATED FROM PYTHON SOURCE LINES 244-252

Post-processing the results
---------------------------
Post-processings such as plots exhibiting the evolutions of the
objective function, the design variables or the constraints can be
extremely useful. The convergence of the objective function, design
variables and of the inequality constraints can be observed in the
following plots. Many other post-processings are available in |g| and
are described in :ref:`Post-processing <post_processing>`.

.. GENERATED FROM PYTHON SOURCE LINES 252-255

.. code-block:: Python


    scenario.post_process("OptHistoryView", save=False, show=True)




.. 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


.. rst-class:: sphx-glr-script-out

 .. code-block:: none


    <gemseo.post.opt_history_view.OptHistoryView object at 0x7f2d1d7853d0>



.. GENERATED FROM PYTHON SOURCE LINES 256-261

.. note::

   Such post-processings can be exported in PDF format,
   by setting ``save`` to ``True`` and potentially additional
   settings (see the :meth:`.Scenario.post_process` options).

.. GENERATED FROM PYTHON SOURCE LINES 263-268

Exporting the problem data.
---------------------------
After the execution of the scenario, you may want to export your data to use it
elsewhere. The :meth:`.Scenario.to_dataset` will allow you to export your
results to a :class:`.Dataset`, the basic |g| class to store data.

.. GENERATED FROM PYTHON SOURCE LINES 268-270

.. code-block:: Python

    dataset = scenario.to_dataset("a_name_for_my_dataset")








.. 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 <tutorials_sg>` 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.697 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-jupyter

      :download:`Download Jupyter notebook: plot_gemseo_in_10_minutes.ipynb <plot_gemseo_in_10_minutes.ipynb>`

    .. container:: sphx-glr-download sphx-glr-download-python

      :download:`Download Python source code: plot_gemseo_in_10_minutes.py <plot_gemseo_in_10_minutes.py>`


.. only:: html

 .. rst-class:: sphx-glr-signature

    `Gallery generated by Sphinx-Gallery <https://sphinx-gallery.github.io>`_