.. DO NOT EDIT.
.. THIS FILE WAS AUTOMATICALLY GENERATED BY SPHINX-GALLERY.
.. TO MAKE CHANGES, EDIT THE SOURCE PYTHON FILE:
.. "tutorials_sg/mdo/plot_gemseo_in_10_minutes.py"
.. LINE NUMBERS ARE GIVEN BELOW.

.. only:: html

    .. note::
        :class: sphx-glr-download-link-note

        Click :ref:`here <sphx_glr_download_tutorials_sg_mdo_plot_gemseo_in_10_minutes.py>`
        to download the full example code

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

.. _sphx_glr_tutorials_sg_mdo_plot_gemseo_in_10_minutes.py:


|g| in 10 minutes
=============================
.. _gemseo_10min:

.. GENERATED FROM PYTHON SOURCE LINES 29-42

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.
The first imports (__future__ and future) enable to run the tutorial
using either a Python 2 or a Python 3 interpreter.

.. GENERATED FROM PYTHON SOURCE LINES 43-51

.. code-block:: default


    from __future__ import absolute_import, division, unicode_literals

    from math import exp, sqrt

    from future import standard_library
    from numpy import array, ones








.. GENERATED FROM PYTHON SOURCE LINES 52-54

Finally, the following functions from the |g| API are imported. They will be
used latter in order to instantiate |g| objects.

.. GENERATED FROM PYTHON SOURCE LINES 54-63

.. code-block:: default

    from gemseo.api import (
        configure_logger,
        create_design_space,
        create_discipline,
        create_scenario,
    )

    configure_logger()





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

 Out:

 .. code-block:: none


    <RootLogger root (INFO)>



.. GENERATED FROM PYTHON SOURCE LINES 64-69

These imports enables to compute mathematical expressions, as well to
instantiate numpy arrays. Numpy arrays are used to store numerical data in
|g| at low level. If you are not confortable with using Numpy, please have a
look at the `Numpy Quickstart tutorial
<https://numpy.org/doc/stable/user/quickstart.html>`_.

.. GENERATED FROM PYTHON SOURCE LINES 69-73

.. code-block:: default



    standard_library.install_aliases()








.. GENERATED FROM PYTHON SOURCE LINES 74-89

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 <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 90-118

.. code-block:: default



    def f_sellar_system(x_local=1.0, x_shared_1=3.0, y_0=1.0, y_1=1.0):
        """
        Objective function
        """
        obj = x_local ** 2 + x_shared_1 + y_0 + exp(-y_1)
        c_0 = 1 - y_0 / 3.16
        c_1 = y_1 / 24.0 - 1.0
        return obj, c_0, c_1


    def f_sellar_0(x_local=1.0, y_1=1.0, x_shared_0=1.0, x_shared_1=3.0):
        """
        Function for discipline 0
        """
        y_0 = x_shared_0 ** 2 + x_shared_1 + x_local - 0.2 * y_1
        return y_0


    def f_sellar_1(y_0=1.0, x_shared_0=1.0, x_shared_1=3.0):
        """
        Function for discipline 1
        """
        y_1 = sqrt(y_0) + x_shared_0 + x_shared_1
        return y_1









.. GENERATED FROM PYTHON SOURCE LINES 119-127

These Python functions can be easily converted into |g|
:class:`.MDODiscipline` objects by using the :class:`.AutoPyDiscipline`
discipline. It enables to automatically wrap 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 instanciated using the
:func:`.create_discipline` function from the |g| :term:`API`:

.. GENERATED FROM PYTHON SOURCE LINES 127-134

.. code-block:: default


    disc_sellar_system = create_discipline("AutoPyDiscipline", py_func=f_sellar_system)

    disc_sellar_0 = create_discipline("AutoPyDiscipline", py_func=f_sellar_0)

    disc_sellar_1 = create_discipline("AutoPyDiscipline", py_func=f_sellar_1)








.. GENERATED FROM PYTHON SOURCE LINES 135-140

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
flexibily and more options. This method is illustrated in the :ref:`Sellar
from scratch tutorial <sellar_from_scratch>`.

.. GENERATED FROM PYTHON SOURCE LINES 140-145

.. code-block:: default


    # We then create a list of disciplines, which will be used later to create a
    # :class:`.MDOScenario`:
    disciplines = [disc_sellar_system, disc_sellar_0, disc_sellar_1]








.. GENERATED FROM PYTHON SOURCE LINES 146-153

.. note::

   For the sake of clarity, these disciplines are overly simple.
   Yet, |g| enables to define 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 155-160

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 160-168

.. 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_0", 1, l_b=-10, u_b=10.0, value=array([4.0]))
    design_space.add_variable("x_shared_1", 1, l_b=0.0, u_b=10.0, value=array([3.0]))
    design_space.add_variable("y_0", 1, l_b=-100.0, u_b=100.0, value=ones(1))
    design_space.add_variable("y_1", 1, l_b=-100.0, u_b=100.0, value=ones(1))








.. GENERATED FROM PYTHON SOURCE LINES 169-177

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 177-186

.. code-block:: default


    scenario = create_scenario(
        disciplines,
        formulation="MDF",
        main_mda_class="MDAGaussSeidel",
        objective_name="obj",
        design_space=design_space,
    )








.. GENERATED FROM PYTHON SOURCE LINES 187-211

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 explicitely 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 utermost importance to be consistant while choosing and
  using the variable names in the disciplines.

.. warning::

   As the workflow and the dataflow are implicitely 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 a 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 211-215

.. code-block:: default


    scenario.add_constraint("c_0", "ineq")
    scenario.add_constraint("c_1", "ineq")








.. GENERATED FROM PYTHON SOURCE LINES 216-223

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 223-226

.. code-block:: default


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





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

 Out:

 .. code-block:: none


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



.. GENERATED FROM PYTHON SOURCE LINES 227-281

The scenario is converged after 7 iterations.
Useful information can be found in the standard output, as shown below:

.. code:: bash

   *** Start MDO Scenario execution ***
   MDOScenario:
   Disciplines: f_sellar_system f_sellar_0 f_sellar_1
   MDOFormulation: MDF
   Algorithm: SLSQP

   Optimization problem:
         Minimize: obj(x_local, x_shared_0, x_shared_1)
   With respect to:
       x_local, x_shared_0, x_shared_1
   Subject to constraints:
   c_0(x_local, x_shared_0, x_shared_1) <= 0
   c_1(x_local, x_shared_0, x_shared_1) <= 0
   Design Space:
   +------------+-------------+-------+-------------+-------+
   | name       | lower_bound | value | upper_bound | type  |
   +------------+-------------+-------+-------------+-------+
   | x_local    |      0      |   1   |      10     | float |
   | x_shared_0 |     -10     |   4   |      10     | float |
   | x_shared_1 |      0      |   3   |      10     | float |
   +------------+-------------+-------+-------------+-------+
   Optimization: |          | 0/10   0% [elapsed: 00:00 left: ?, ? iters/sec]
   Optimization: |██████    | 6/10  60% [elapsed: 00:00 left: 00:00, 56.08
   iters/sec obj:  3.18 ]
   Optimization result:
   Objective value = 3.18339398657
   The result is feasible.
   Status: 0
   Optimizer message: Optimization terminated successfully.
   Number of calls to the objective function by the optimizer: 7
   Constraints values:
    c_1 = -0.843530155261
    c_0 = 1.59205981731e-13

    Design Space:
   +------------+-------------+-----------------------+-------------+-------+
   | name       | lower_bound |         value         | upper_bound | type  |
   +------------+-------------+-----------------------+-------------+-------+
   | x_local    |      0      |           0           |      10     | float |
   | x_shared_0 |     -10     |    1.97763739026546   |      10     | float |
   | x_shared_1 |      0      | 5.698379135171542e-13 |      10     | float |
   +------------+-------------+-----------------------+-------------+-------+
   *** MDO Scenario run terminated in 0:00:00.118049 ***

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

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 291-294

.. code-block:: default


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




.. rst-class:: sphx-glr-horizontal


    *

      .. image:: /tutorials_sg/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_001.png
          :alt: Evolution of the optimization variables
          :class: sphx-glr-multi-img

    *

      .. image:: /tutorials_sg/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_002.png
          :alt: Evolution of the objective value
          :class: sphx-glr-multi-img

    *

      .. image:: /tutorials_sg/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_003.png
          :alt: Distance to the optimum
          :class: sphx-glr-multi-img

    *

      .. image:: /tutorials_sg/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_004.png
          :alt: Hessian diagonal approximation
          :class: sphx-glr-multi-img

    *

      .. image:: /tutorials_sg/mdo/images/sphx_glr_plot_gemseo_in_10_minutes_005.png
          :alt: Evolution of the inequality constraints
          :class: sphx-glr-multi-img


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

 Out:

 .. code-block:: none

    /home/docs/checkouts/readthedocs.org/user_builds/gemseo/conda/3.0.3/lib/python3.8/site-packages/gemseo/post/opt_history_view.py:312: UserWarning: FixedFormatter should only be used together with FixedLocator
      ax1.set_yticklabels(y_labels)
    /home/docs/checkouts/readthedocs.org/user_builds/gemseo/conda/3.0.3/lib/python3.8/site-packages/gemseo/post/opt_history_view.py:716: MatplotlibDeprecationWarning: default base will change from np.e to 10 in 3.4.  To suppress this warning specify the base keyword argument.
      norm=SymLogNorm(linthresh=linthresh, vmin=-vmax, vmax=vmax),
    /home/docs/checkouts/readthedocs.org/user_builds/gemseo/conda/3.0.3/lib/python3.8/site-packages/gemseo/post/opt_history_view.py:626: MatplotlibDeprecationWarning: default base will change from np.e to 10 in 3.4.  To suppress this warning specify the base keyword argument.
      norm=SymLogNorm(linthresh=1.0, vmin=-vmax, vmax=vmax),
    /home/docs/checkouts/readthedocs.org/user_builds/gemseo/conda/3.0.3/lib/python3.8/site-packages/gemseo/post/opt_history_view.py:619: MatplotlibDeprecationWarning: Passing parameters norm and vmin/vmax simultaneously is deprecated since 3.3 and will become an error two minor releases later. Please pass vmin/vmax directly to the norm when creating it.
      im1 = ax1.imshow(

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



.. GENERATED FROM PYTHON SOURCE LINES 295-300

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

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.063 seconds)


.. _sphx_glr_download_tutorials_sg_mdo_plot_gemseo_in_10_minutes.py:


.. only :: html

 .. container:: sphx-glr-footer
    :class: sphx-glr-footer-example



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



  .. container:: sphx-glr-download sphx-glr-download-jupyter

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


.. only:: html

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

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