905 docs (#909)

* doc fixes

* analytic phase doc

* typo

---------

Co-authored-by: swryan <swryan@users.noreply.github.com>

docs/dymos_book/features/phases/analytic_phases.ipynb

@@ -92,7 +92,7 @@
     "AnalyticPhase has the notion of _states_ but they are generally just \"special\" outputs of the ODE solution system.  They are automatically added to the timeseries output with the name `{path.to.phase}.states:{state_name}`.\n",
     "\n",
     "Finally, AnalyticPhase doesn't have the notion of a multi-segment _grid_ on which the solution is calculated.\n",
-    "To keep things as simple as possible, the use provides the phase with a number of nodes at which the solution is requested (lets call it _N_ for now).\n",
+    "To keep things as simple as possible, the user provides the phase with a number of nodes at which the solution is requested (lets call it _N_ for now).\n",
     "Dymos then provides the solution at _N_ Legendre-Gauss-Lobatto (LGL) nodes.\n",
     "This design decision was made because phase types use the LGL nodes to define the input times of polynomial control variables.\n",
     "This means that values of an output of an `AnalyticPhase` can be fed into another phase as a polynomial control."
@@ -284,7 +284,7 @@
     "Since AnalyticPhases only output state values, there is no notion of a target of state variable in an `AnalyticPhase`.\n",
     "In an `AnalyticPhase`, states need a *source*.\n",
     "Much like timeseries outputs, when we add a state to the `AnalyticPhase` we can specify the entire path, and the last bit of the path (after the last period) will be used for the name of the state.\n",
-    "Any just as `add_timeseries_output` uses argument `output_name` to disambiguate the name of the timeseries output if necessary, `add_state` will accept `state_name` if the last portion of the path is ambiguous."
+    "And just as `add_timeseries_output` uses argument `output_name` to disambiguate the name of the timeseries output if necessary, `add_state` will accept `state_name` if the last portion of the path is ambiguous."
    ]
   },
   {
@@ -341,14 +341,14 @@
     "## Different ways to handle the phase linkage for state continuity\n",
     "\n",
     "At this point we need to choose how to enforce state continuity.\n",
-    "The we cannot simply use `traj.link_phases(['first_phase', 'second_phase'], ['x'], connected=True)` because **the initial value of state `x` is not an input to the phase**.\n",
+    "We cannot simply use `traj.link_phases(['first_phase', 'second_phase'], ['x'], connected=True)` because **the initial value of state `x` is not an input to the phase**.\n",
     "\n",
     "One might think to link state `x` from `first_phase` to parameter `x0` from second phase, but that is also not correct, because `x0` is not the initial value of `x` in the phase but the value of `x` at `t=0`.\n",
     "We could redefine `x0` to be the value at the initial time, however.\n",
     "\n",
     "Valid options here would be to link the states together with unconnected phases, using a constraint:\n",
     "\n",
-    "`traj.link_phases(['first_phase', 'second_phase'], ['x'], connected=True)`\n",
+    "`traj.link_phases(['first_phase', 'second_phase'], ['x'], connected=False)`\n",
     "\n",
     "Alternatively, we could either link parameters `x0` together in both phases (a connection would be fine) or use a trajectory-level parameter to pass a single value of `x0` to both phases.\n",
     "\n",

docs/dymos_book/features/phases/variables.ipynb

@@ -167,10 +167,11 @@
    ]
   },
   {
+   "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The Radau Pseudospectral and Gauss Lobatto phases types in Dymos use differential defects to\n",
+    "The Radau Pseudospectral and Gauss Lobatto phase types in Dymos use differential defects to\n",
     "approximate the evolution of the state variables with respect to time.  In addition to scaling\n",
     "the state values, scaling the defect constraints correctly is important to good performance of\n",
     "the collocation algorithms.  This is accomplished with the `defect_scaler` or `defect_ref` options.\n",

docs/dymos_book/getting_started/intro_to_dymos/intro_ivp.ipynb

@@ -156,6 +156,21 @@
     "Some elements of this code will be explained later, but we'll hit the highlights now."
    ]
   },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {
+    "tags": [
+     "active-ipynb",
+     "remove-input",
+     "remove-output"
+    ]
+   },
+   "outputs": [],
+   "source": [
+    "%matplotlib inline"
+   ]
+  },
   {
    "cell_type": "code",
    "execution_count": null,
@@ -222,7 +237,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]
@@ -249,7 +264,7 @@
     "   2. State variables are vectors whose values are provided throughout the Phase.  Here they're all being filled with a single value (10.0 for displacement, 0.0 for the velocity)\n",
     "6. `Problem.run_model` is called.  This executes the Problem's `model` one time.  This is a necessary step before using the `Trajectory.simulate` method.\n",
     "7.  The trajectory is simulated using the `simulate()` method and the results returned as an OpenMDAO Problem instance called `sim_out`.\n",
-    "8.  The states are plotted using values obtained from the _timeseries_.  Phases contain `_timeseries_` data that provides contiguous values regardless of the transcription used.\n",
+    "8.  The states are plotted using values obtained from the _timeseries_.  Phases contain _`timeseries`_ data that provides contiguous values regardless of the transcription used.\n",
     "\n",
     "Method `simulate` exists on both Trajectory and Phase objects.\n",
     "It uses the [scipy.integrate.solve_ivp](https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.solve_ivp.html) function to propagate the states defined in each phase of the trajectory from their initial values at the initial time to some final value at `time = t_initial + t_duration`.\n",
@@ -293,7 +308,7 @@
     "import openmdao.api as om\n",
     "import dymos as dm\n",
     "import matplotlib.pyplot as plt\n",
-    "plt.switch_backend('Agg')  # disable plotting to the screen\n",
+    "# plt.switch_backend('Agg')  # disable plotting to the screen\n",
     "\n",
     "from dymos.examples.oscillator.oscillator_ode import OscillatorODE\n",
     "\n",
@@ -350,7 +365,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]
@@ -384,7 +399,7 @@
     "import openmdao.api as om\n",
     "import dymos as dm\n",
     "import matplotlib.pyplot as plt\n",
-    "plt.switch_backend('Agg')  # disable plotting to the screen\n",
+    "# plt.switch_backend('Agg')  # disable plotting to the screen\n",
     "\n",
     "from dymos.examples.oscillator.oscillator_ode import OscillatorODE\n",
     "\n",
@@ -451,7 +466,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]

docs/dymos_book/getting_started/intro_to_dymos/intro_segments.ipynb

@@ -139,7 +139,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]
@@ -236,7 +236,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]
@@ -323,7 +323,7 @@
     "    sim = axes[i].plot(t_sim, sim_out.get_val(f'traj.phase0.timeseries.states:{state}'), '-')\n",
     "    axes[i].set_ylabel(state)\n",
     "axes[-1].set_xlabel('time (s)')\n",
-    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), 'lower right', ncol=2)\n",
+    "fig.legend((sol[0], sim[0]), ('solution', 'simulation'), loc='lower right', ncol=2)\n",
     "plt.tight_layout()\n",
     "plt.show()"
    ]

docs/dymos_book/getting_started/transcriptions.md

@@ -77,7 +77,7 @@ While faster, implicit techniques impose far more defect constraints on the prob
 In some cases, scaling the optimization problem can be a challenge and convergence is poor.
 For instance, if the thrust of a rocket engine is taken from experimental data, it can be extremely noisy.
 Without first smoothing the data, an implicit simulation of the resulting trajectory may be difficult.
-In this case, explicit intgration methods can power through and provide _an_ answer, even if it is subject to some amount of error.
+In this case, explicit integration methods can power through and provide _an_ answer, even if it is subject to some amount of error.
 
 **Explicit integration, at least using a fixed-step form, doesn't fail to provide an answer - but it's important that the user verify its accuracy.**
 
@@ -88,5 +88,5 @@ The equations of motion used in this problem are singular in vertical flight - t
 It is relatively easy to prescribe a profile of the angle-of-attack history (the control) that sends the aircraft into vertical flight when the integration is required to follow it.
 
 Conversely, the collocation techniques decouple the proposed control history and the trajectory.
-Rather than being governed by the control, the flight path angle at various times throughout the trajectory is itself a design variable, and can be bound to values such that avoid the singularities.
+Rather than being governed by the control, the flight path angle at various times throughout the trajectory is itself a design variable, and can be bound to values such that the singularities are avoided.
 The optimizer will then work to make the control history compatible with the corresponding state trajectory, but the two are only compatible when the defect constraints are satisfied.

docs/dymos_book/index.md

@@ -7,7 +7,7 @@ While it can optimize typical optimal control problems, its key feature is the a
 Other optimization software frequently relies on the parameterization of the hardware models to, for instance, approximate the mass of an engine as a function of its thrust level.
 Instead, Dymos allows you to impose higher-fidelity design considerations on these subsystems - from simple parameterized models to high-fidelity CFD models, and apply the resulting subsystem designs to the trajectory profile.
 
-To do this, Dymos relies on ability of OpenMDAO to compute accurate derivatives very efficiently.
+To do this, Dymos relies on the ability of OpenMDAO to compute accurate derivatives very efficiently.
 This capability enables users of Dymos to embed iterative procedures within their system dynamics.
 While normally this would significantly impair performance, Dymos can optimize such systems with minimal performance degradation, freeing the user from reformulating their design specifically for the purposes of the optimal control implementation.
 
@@ -19,7 +19,7 @@ While normally this would significantly impair performance, Dymos can optimize s
 -   Transform typical state variables into control variables (differential inclusion {cite}`Seywald1994`).
 -   Use nonlinear solvers to satisfy the collocation constraints.
 -   Single and multiple shooting within the same interface.
--   Leverage multiprocessing capabilities to improve performance
+-   Leverage multiprocessing capabilities to improve performance.
 
 ## Why Dymos?
 
@@ -52,7 +52,7 @@ But with the state-of-the-art differentiation approach of OpenMDAO, built upon t
 This enables more efficient optimization via differential inclusion {cite}`Seywald1994`, and allows us to employ shooting methods within the pseudospectral framework.
 
 Some developers involved in Dymos are involved with NASA's legacy optimal control software, OTIS.
-The general approach used by Dymos is similar to that of OTIS (trajectories divided into time portions called Phases, dynamic controls and static parameters, and both bound constraints as well as nonlinear boundary constraints and path constraints are all notions carried over from OTIS.
+The general approach used by Dymos is similar to that of OTIS (trajectories divided into time portions called Phases, dynamic controls and static parameters, and both bound constraints as well as nonlinear boundary constraints and path constraints are all notions carried over from OTIS).
 OTIS was pioneering software and offers some great capabilities, but it also lacks a lot of desirable modern features that have been developed by the community since its inception over thirty years ago.
 Dymos features a more modular way for users to define their dynamics, additional pseudospectral methods, and better differentiation approaches for more reliable convergence.