Add compatibility for OpenMDAO 3.16 (#37)

* Updated docs for updated OAS

* Fixed src_indices error in OAS aerostruct tests (in OM 3.16.0), not sure if this is OM bug or expected

* Addressed src_indices deprecation warning in takeoff phases

* Small changes for src_indices to make backward compatible with OpenMDAO 3.10.0

* Simplified setup.py and GHA yaml to install only necessary packages (no more openmdao[docs])

* Added call directly to aerostructural tests to figure out why the stall

* Changed parallel pool initialization in OAS integration to properly clean up pool

* Trying to change OMP_NUM_THREADS to 1 to improve OAS training time

* Try something different with environment variable

* I was being dumb, there's a GHA way of setting environment vars

* Debugging pytest on OAS stuff

* Adding coverage to test pytest call

* Added cleanup for multiprocessing with pytest-cov

* Removed pytest-cov parallel pool cleanup since it doesn't work since python 3.8 (and removed commented out old steady flight phase)

* Removed dependencies to old OpenMDAO docs modules (embed-code -> literalinclude)

* Removed redbaron dependency, created docs extras_require, and removed OAS debug from GHA yaml

* Bumped RTD build to use Python 3.8

* Added plot extras_require and installed docs extras_require on GHA

* Removed some stuff from conf.py that's already in the sphinx_mdolab_theme one

* Fixed code blocks so the use the MDO Lab
's Sphinx theme

* Dedented ODE integration code in docs

* Fixed monospaced font in docs

* Removed commented out code in conf.py

* Removed monospaced fonts from RTD headers

* Fixed underline problem in RST files

* Removed italics to fix monospace in prop modeling docs

* Fixed a typo in docs that said OpenMDAO instead of OpenConcept

.github/workflows/openconcept.yaml

@@ -13,6 +13,8 @@ jobs:
       matrix:
         os: ["ubuntu-latest", "windows-latest", "macos-latest"]
       fail-fast: false
+    env:
+      OMP_NUM_THREADS: 1
     defaults:
       run:
         shell: bash -l {0}
@@ -29,8 +31,8 @@ jobs:
         conda install numpy scipy
     - name: Install
       run: |
-        pip install coverage pytest-cov sphinx_rtd_theme
         pip install .[testing]
+        pip install .[docs]
     - name: Download engine deck surrogate model
       run: |
         curl -L -o engine_kriging_surrogate_model.tar.gz http://umich.edu/~mdolaboratory/repo_files/openconcept/engine_kriging_surrogate_model.tar.gz
@@ -44,7 +46,7 @@ jobs:
       run: |
         python -m pytest --cov-config=.coveragerc --cov=openconcept --cov-report=xml
     - name: Upload coverage to Codecov
-      if: ${{ matrix.os == 'ubuntu-latest'}}
+      if: ${{ matrix.os == 'ubuntu-latest' }}
       uses: codecov/codecov-action@v2
       with:
         fail_ci_if_error: true

readthedocs.yml → .readthedocs.yml

@@ -8,10 +8,10 @@ formats:
   - epub
 
 python:
-  version: 3.6
+  version: 3.8
   install:
     - method: pip
       path: .
       extra_requirements:
-        - testing
+        - docs
   system_packages: true

docs/conf.py

@@ -14,8 +14,6 @@
 #
 import os
 import sys
-import subprocess
-import openmdao
 import openconcept
 
 from sphinx_mdolab_theme.config import *
@@ -207,21 +205,12 @@ def patched_parse(self):
 # ones.
 
 extensions = [
-    'sphinx.ext.autodoc',
     'sphinx.ext.autosummary',
     'sphinx.ext.doctest',
 	'sphinx.ext.napoleon',
     'sphinx.ext.todo',
     'sphinx.ext.coverage',
-    'sphinx.ext.mathjax',
-    'sphinx.ext.viewcode',
-    'embed_code',
-    'embed_options',
-    'embed_compare',
-    'embed_shell_cmd',
-    'embed_bibtex',
-    'embed_n2',
-    'tags'
+    "sphinx_copybutton",
 ]
 autodoc_inherit_docstrings = False
 autodoc_member_order = 'bysource'
@@ -247,43 +236,14 @@ def patched_parse(self):
 # Usually you set "language" from the command line for these cases.
 language = None
 
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This pattern also affects html_static_path and html_extra_path .
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
 
 # -- Options for HTML output -------------------------------------------------
 
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-#
-html_theme = 'sphinx_rtd_theme'
-html_style = 'css/override_theme.css'
-# Theme options are theme-specific and customize the look and feel of a theme
-# further.  For a list of options available for each theme, see the
-# documentation.
-#
-# html_theme_options = {}
-
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
-# Custom sidebar templates, must be a dictionary that maps document names
-# to template names.
-#
-# The default sidebars (for documents that don't match any pattern) are
-# defined by theme itself.  Builtin themes are using these templates by
-# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
-# 'searchbox.html']``.
-#
-# html_sidebars = {}
-
 
 # -- Options for HTMLHelp output ---------------------------------------------
 

docs/features/odeint/ode_integration.rst

@@ -6,19 +6,21 @@ ODE Integration
 
 OpenConcept includes built-in utilities for integrating ODEs, a frequent task in airplane performance analysis.
 
-`Component`, `Group`, and Connections
--------------------------------------
+Component, Group, and Connections
+---------------------------------
 If users are running examples or instantiating OpenConcept native components (e.g. the battery), there's no need to know what's going on under the hood in the ODE integration.
 However, for writing custom analysis routines, developing new components, or troubleshooting new airplane models, some background can be helpful.
-The `openconcept.Trajectory` class acts just like an OpenMDAO `Group` except that it adds the ability to automatically link integrated states from one phase of a trajectory to the next using the `link_phases` method.
-The `openconcept.Phase` class acts just like an OpenMDAO `Group` except it finds all the integrated states and automatically links the time duration variable to them. 
-It also collects the names of all the integrated states so that the `Trajectory` can find them and link them.
-The `openconcept.IntegratorGroup` class again acts just like OpenMDAO's `Group` except it adds an ODE Integration component (called ode_integ), locates output variables tagged with the "integrate" tag, and automatically connects the tagged rate source to the integrator.
-Any state you wish to be automatically integrated needs to be held in an `IntegratorGroup`.
-However, `IntegratorGroup` instances can be buried deep in a model made up of mainly plain `Group`. 
+The ``openconcept.Trajectory`` class acts just like an OpenMDAO ``Group`` except that it adds the ability to automatically link integrated states from one phase of a trajectory to the next using the ``link_phases`` method.
+The ``openconcept.Phase`` class acts just like an OpenMDAO ``Group`` except it finds all the integrated states and automatically links the time duration variable to them. 
+It also collects the names of all the integrated states so that the ``Trajectory`` can find them and link them.
+The ``openconcept.IntegratorGroup`` class again acts just like OpenMDAO's ``Group`` except it adds an ODE Integration component (called ode_integ), locates output variables tagged with the "integrate" tag, and automatically connects the tagged rate source to the integrator.
+Any state you wish to be automatically integrated needs to be held in an ``IntegratorGroup``.
+However, ``IntegratorGroup`` instances can be buried deep in a model made up of mainly plain ``Group``. 
 
 The following example illustrates the usage of this feature.
 The tags following the "integrate" tag define the name, units, and default values of the integrated output.
 
-.. embed-code::
-    openconcept.analysis.tests.test_trajectories.TestForDocs.trajectory_example
+.. literalinclude:: /../openconcept/analysis/tests/test_trajectories.py
+    :pyobject: TestForDocs.trajectory_example
+    :language: python
+    :dedent: 4

docs/features/openmdao/openmdao_basics.rst

@@ -9,25 +9,26 @@ It is a Python-based environment for modeling, simulation, and optimization whic
 This greatly reduces the computational cost of solving nonlinear equations and performing gradient-based optimization.
 
 Users unfamiliar with OpenMDAO are encouraged to visit the `getting started <http://openmdao.org/twodocs/versions/latest/getting_started/index.html>`_ page on their doc site.
-I will cover several portions of the OpenMDAO package that are used extensively in OpenMDAO.
+I will cover several portions of the OpenMDAO package that are used extensively in OpenConcept.
 
-`Component`, `Group`, and Connections
--------------------------------------
-OpenMDAO models are generally made up of numerous `Component` instances.
-Components can be combined into a `Group` of components.
+Component, Group, and Connections
+---------------------------------
+OpenMDAO models are generally made up of numerous ``Component`` instances.
+Components can be combined into a ``Group`` of components.
 Each component (with some exceptions) has *inputs* and *outputs*.
 When outputs of one component are connected to inputs of another, components can be chained together and more complex models are formed.
 
 The following simple model calculates the drag on an airplane using a simple drag polar formulation.
 
 Pay attention to these four class methods which are very common in OpenMDAO models:
-    - The `initialize` method allows the user to define options which are instantiated with the component in a larger model.
-    - The `setup` method declares inputs, outputs, and the nature of the derivatives of outputs with respect to inputs (this is important for reasons that will be addressed later).
-    - The `compute` method establishes how the outputs should be computed.
-    - The `compute_partials` method tells the component how to compute partial derivatives.
+    - The ``initialize`` method allows the user to define options which are instantiated with the component in a larger model.
+    - The ``setup`` method declares inputs, outputs, and the nature of the derivatives of outputs with respect to inputs (this is important for reasons that will be addressed later).
+    - The ``compute`` method establishes how the outputs should be computed.
+    - The ``compute_partials`` method tells the component how to compute partial derivatives.
 
-.. embed-code::
-    openconcept.analysis.aerodynamics.PolarDrag
+.. literalinclude:: /../openconcept/analysis/aerodynamics.py
+    :pyobject: PolarDrag
+    :language: python
 
 Connections in OpenMDAO can be `defined explicitly <http://openmdao.org/twodocs/versions/latest/features/core_features/grouping_components/connect.html>`_, or `semi-implicitly through variable promotion <http://openmdao.org/twodocs/versions/latest/features/core_features/grouping_components/add_subsystem.html>`_.
 Refer to the OpenMDAO docs for more details.
@@ -36,23 +37,23 @@ In general, I use variable promotion if I have some high-level design parameters
 I use structured, unambiguous variable names so I can find and replace them if I need to refactor the code.
 Explicit connections are useful down at lower levels in the model where only one or two connections need to be made and it's unlikely that end users will edit the model.
 
-The `Problem` Class
--------------------
-To perform analysis and/or optimization, OpenMDAO requires a `Problem` object to be instantiated.
-Examples of problems representative of aircraft design can be found in the OpenConcept `examples/` folder.
+The Problem Class
+-----------------
+To perform analysis and/or optimization, OpenMDAO requires a ``Problem`` object to be instantiated.
+Examples of problems representative of aircraft design can be found in the OpenConcept ``examples/`` folder.
 
-The `Problem` object needs some attributes to be set in order to work properly.
-    - `problem.model` is an OpenMDAO `Group` containing all the necessary `Component` or `Group` objects to model the problem. It is the problem physics.
-    - `problem.driver` is the optimization algorithm (required in order to do MDO). A common choice of driver is the `ScipyOptimizeDriver`.
-    - `problem.nonlinear_solver` is required for problems which have implicit state variables. OpenMDAO's `NewtonSolver` is amazingly efficient at solving problems with accurate derivatives.
-    - `problem.linear_solver` is required when Newton methods are used for nonlinear systems, since a linear solve is a necssary component in computing the Newton step.
+The ``Problem`` object needs some attributes to be set in order to work properly.
+    - ``problem.model`` is an OpenMDAO ``Group`` containing all the necessary ``Component`` or ``Group`` objects to model the problem. It is the problem physics.
+    - ``problem.driver`` is the optimization algorithm (required in order to do MDO). A common choice of driver is the ``ScipyOptimizeDriver``.
+    - ``problem.nonlinear_solver`` is required for problems which have implicit state variables. OpenMDAO's ``NewtonSolver`` is amazingly efficient at solving problems with accurate derivatives.
+    - ``problem.linear_solver`` is required when Newton methods are used for nonlinear systems, since a linear solve is a necssary component in computing the Newton step.
 
 If optimization is being done, the following methods must be employed:
-    - `problem.model.add_design_var()` method tells the optimizer which variables can be altered during the optimization.
-    - `problem.model.add_objective()` method sets the objective function for the optimization (the variable to be minimized/maximized).
-    - `problem.model.add_constraint()` method adds constraints (since most MDO problems are constrained in some way)
+    - ``problem.model.add_design_var()`` method tells the optimizer which variables can be altered during the optimization.
+    - ``problem.model.add_objective()`` method sets the objective function for the optimization (the variable to be minimized/maximized).
+    - ``problem.model.add_constraint()`` method adds constraints (since most MDO problems are constrained in some way)
 
-Finally, the `problem.setup()` method is run once the model, settings, and optimization are all defined. This is required for OpenMDAO to work properly.
+Finally, the ``problem.setup()`` method is run once the model, settings, and optimization are all defined. This is required for OpenMDAO to work properly.
 
 Setting and Accessing Values
 ----------------------------
@@ -64,8 +65,8 @@ If variable values need to be set (for example, initial design variable values),
 
 Running the Model/Optimization
 ------------------------------
-To run an analysis-only problem, the `problem.run_model()` method will execute all the components.
-If optimization is being conducted, the `problem.run_driver()` method must be used instead.
+To run an analysis-only problem, the ``problem.run_model()`` method will execute all the components.
+If optimization is being conducted, the ``problem.run_driver()`` method must be used instead.
 
 Partial Derivatives
 -------------------
@@ -77,15 +78,15 @@ OpenMDAO uses the *partial* derivatives of each component and assembles them tog
 If you use the pre-built OpenConcept components, you don't need to worry about this at all. Enjoy the efficient and accurate solutions.
 
 If you build your own, custom components, you need to make sure that you're supplying accurate partial derivatives.
-This usually means either ensuring your model can handle complex input and output variables (to use the complex step method), or supplying analytic derivatives to each component using the `compute_partials` method.
-If you do this, you should make sure to use OpenMDAO's `check_partials` method regularly.
+This usually means either ensuring your model can handle complex input and output variables (to use the complex step method), or supplying analytic derivatives to each component using the ``compute_partials`` method.
+If you do this, you should make sure to use OpenMDAO's ``check_partials`` method regularly.
 
 **Errors in partial derivatives can cause MAJOR Newton and optimizer convergence issues which can be difficult to debug.**
 
 Recording and Retrieving Results
 --------------------------------
 OpenMDAO includes a SQLlite database interface for recording the results of model/optimization runs.
-First, instantiate an `openmdao.api.SqliteRecorder` object. Then attach the object to the problem.model object, like this:
+First, instantiate an ``openmdao.api.SqliteRecorder`` object. Then attach the object to the problem.model object, like this:
 
 .. code-block:: python
 
@@ -99,7 +100,7 @@ While the utility has many uses (see the OpenMDAO docs), every user should make
 
 Putting it all Together
 -----------------------
-The `examples/TBM850.py` `script <https://github.com/mdolab/openconcept/blob/master/examples/TBM850.py>`_ models a single-engine turboprop aircraft and uses all of the elements mentioned on this page in an OpenConcept context.
+The ``examples/TBM850.py`` `script <https://github.com/mdolab/openconcept/blob/master/examples/TBM850.py>`_ models a single-engine turboprop aircraft and uses all of the elements mentioned on this page in an OpenConcept context.
 
 
 

docs/features/propulsion/prop_modeling.rst

@@ -11,22 +11,24 @@ Single Turboprop Example
 ------------------------
 
 This example illustrates the simples possible case (turboprop engine connected to a propeller).
-The propulsion system is instantiated as an OpenMDAO `Group`.
+The propulsion system is instantiated as an OpenMDAO ``Group``.
 
-*Source: `examples/propulsion_layouts/simple_turboprop.py`*
+Source: ``examples/propulsion_layouts/simple_turboprop.py``
 
-.. embed-code::
-    examples.propulsion_layouts.simple_turboprop.TurbopropPropulsionSystem
+.. literalinclude:: /../examples/propulsion_layouts/simple_turboprop.py
+    :pyobject: TurbopropPropulsionSystem
+    :language: python
 
 Series Hybrid Example
 ---------------------
 
 This example illustrates the complexities which arise when electrical components are included.
 
-*Source: `examples.propulsion_layouts.simple_series_hybrid.py`*
+Source: ``examples/propulsion_layouts/simple_series_hybrid.py``
 
-.. embed-code::
-    examples.propulsion_layouts.simple_series_hybrid.SingleSeriesHybridElectricPropulsionSystem
+.. literalinclude:: /../examples/propulsion_layouts/simple_series_hybrid.py
+    :pyobject: SingleSeriesHybridElectricPropulsionSystem
+    :language: python
 
 Components
 ----------

docs/index.rst

@@ -34,7 +34,6 @@ Getting Started
 Dependencies
 ------------
 This toolkit requires the use of `OpenMDAO <https://openmdao.org>`__ 3.10.0 or later due to backward-incompatible changes. OpenMDAO requires a recent NumPy and SciPy.
-If you'd like to use the OpenAeroStruct features of OpenConcept, OpenMDAO 3.10 is required because that is the newest version supported by OpenAeroStruct at the time of writing this.
 Python 3.8 is recommended since it is the version with which the code is tested, but newer Python versions will likely work as well.
 
 ---------------
@@ -48,7 +47,7 @@ Benjamin J. Brelje and Joaquim R.R.A. Martins.
 2018 AIAA/IEEE Electric Aircraft Technologies Symposium,
 AIAA Propulsion and Energy Forum, (AIAA 2018-4979) DOI: 10.2514/6.2018-4979
 
-::
+.. code-block:: bibtex
 
     @inproceedings{Brelje2018,
 	address = {{C}incinnati,~{OH}},
@@ -64,7 +63,7 @@ If using the integrated OpenAeroStruct VLM or aerostructural aerodynamic models,
 
 Eytan J. Adler and Joaquim R.R.A. Martins, "Aerostructural wing design optimization considering full mission analysis", 2022 AIAA SciTech Forum, San Diego, CA, January 2022. DOI: 10.2514/6.2022-0382
 
-::
+.. code-block:: bibtex
 
     @inproceedings{Adler2022a,
 	author      = {Eytan J. Adler and Joaquim R. R. A. Martins},

openconcept/__init__.py

@@ -1 +1 @@
-__version__ = '0.4.0'
+__version__ = '0.4.1'