Time grid options

[PierreMartinon]

Besides passing an explicit time grid as a vector of steps, there are some further directions to explore, as mentioned in #119 and ???. Practically, the argument time_grid could be reused for different features.

By increasing complexity (or so I think):

• time_grid=:refined performs a basic discrete continuation on the time steps, starting from a coarse uniform grid and refining until the prescribed grid_size is met. The sequence of intermediate problems is solved with a limited number of iterations, using warm start. The point of the continuation is to provide a good initial guess for the final solve, at a limited computational cost thanks to the smaller grids and limited iterations. @ocots and I have experimented a bit on this kind of feature, that could be automated.
• time_grid=:optimized means that all time steps become optimization variables in the discretized problem. More precisely, the Dt_i, which just have to be strictly positive to ensure a properly increasing time grid. Similar to a Jump feature. I did some very basic preliminary tests with some "creative" OCP reformulation, but this needs a proper implementation.
• time_grid=:adaptive would be an improvement of the first one above, with some adaptive refinement of the time grid. Instead of just using uniform grids with more steps, individual steps could be moved, added or removed , maybe based on some local error analysis. Optimization would then resume with a warm start. I know @joseph-gergaud likes this one :D

See also

• Basic grid refinement  #119
• crude example of basic grid refinement #158 a crude attempt at optimizing time steps, ok on double integrator but already failing on goddard

[PierreMartinon]

On local error: a standard way to assess the local error is to compare two different discretisation formulas. We could write a function check_local_error that would take a trajectory and try to check this ? As an offline diagnostic, we can just recompute the trajectory (with the same initial conditions and control) using a high precision variable step method, and check the error wrt the original one. Here we even have an estimate of the total error. This information may be used to drive an iterative optimization strategy, eg with increasingly precise discretisations ?

The double formula idea can probably be included somehow in the NLP directly, although this would roughly double the size due to the second trajectory. Such added cost is unlikely to be worth it unless it can allow to significantly improve the optimization overall. Maybe in a format where all time steps are optimization variables (ie only the grid size is fixed), and the additional info from the local error can be used to optimize better the time steps, maybe by adding to the objective the minimization of the sum of all local errors ?

Note: for this kind of manipulations, it may be useful to have a fully discrete solution structure instead of the functional (interpolated) OCP one. This new struct can be local to CTDirect and used only when explicitly requested.

Steps

• struct for the raw discrete solution (ie without interpolation), with solve option
• offline function check_trajectory_error to check the integration error
• exploit this information in discrete continuation, eg increase grid size until target error is reached. This could give a better comparison of discretisation formulas.
• NLP with all time steps as optimization variables (via a specific version of set_time_grid that would return the relevant part of the variables; with solve option)
• NLP with double discretisation; variant of check_trajectory_error to compute the local error from the discrete solution (NB. compare results with offline version !)
• NLP with double discretisation and optimized time steps in order to minimize local errors overall