Allow timeseries to provide interpolated rates of output variables.

[robfalck]

Issue Type

• [ ] Bug
• [x] Enhancement
• [ ] Docs
• [ ] Miscellaneous

Description

The timeseries component serves as the consistent way to retrieve outputs from Dymos regardless of the method used (and the location of the states, controls, ODE outputs, etc in the model hierarchy). Recently it's also become the place where boundary and path constraints are applied to values - adding a path or boundary constraint would also add a corresponding timeseries output, and the constraint bounds would be applied there.

Recently there have been a few cases where knowing or constraining the approximate rates of change of a variable is needed. Since each segment in a Dymos pseudospectral transcription is a polynomial, by knowing the values of a variable at the nodes in the timeseries, we can use a differentiation matrix to compute the approximate rates of that variable along the segment. This is exactly what the control interpolation component does for control values.

In fact, the pseudospectral timeseries output component already multiplies the incoming values by the interpolation matrix $[L]$ when the input and output grids are not the same. Implementation of this story for the pseudospectral phases would just require that we save and use the differentiation matrix $[D]$ for computing rates of requested outputs.

Proposed API

1. The signature of add_timeseries_output will change to add_timeseries_output(var, ..., val=True, rate=False). The defaults provide the current functionality. Setting rate=True would add an output named f'{output_name}_rate' to the timeseries outputs, which would be computed by multiplying the incoming values by the differentiation matrix pertaining to the phase transcription and the timeseries transcription.

2. This approach makes it so that the computed quantities are outputs of the phase. Since they are computed downstream of the ODE, they cannot be used directly by the ODE. In theory, connecting the resulting rates back into the phase as a control should work, but being implicit it will result in a performance hit.

3. Handling this in the simulation transcription (SolveIVP) can be done applying some curve fit to the simulation outputs within each segment. There will be some interpolation error or runge phenomenon in all likelihood, but since SolveIVP is only used for sanity-checks and not optimization, this shouldn't be a big deal.

4. Handling this in ExplicitShooting could be similar to SolveIVP, but since that transcription is used for optimization, we might see more accuracy issues. Using a finite difference based on a value from the previous timestep would fail at the start of each segment since the previous values of the variables to be differentiated are undefined.

Example

N/A

Environment

N/A