Non uniform time grid

[ocots]

@PierreMartinon Can you please explain how the argument time_grid from the solve functions works when the final time is free, for instance for a time minimal control problem?

CTDirect.jl/ext/CTSolveExt.jl

Line 66 in 27405de

time_grid=nothing,

[PierreMartinon]

The time grid used internally is normalized (ie in [0,1]) and the given grid will be normalized if needed. This is why the internal field is named docp.NLP_normalized_time_grid. During the optimization the actual time steps t_i are recomputed with respect to the current values of t0 and tf.

This is what we did in bocop, and as far as I know this is the only way to handle the free times case. More precisely the user will specify the relative spacing of the time steps. For instance, an input grid [0, 0.25, 1] for a free tf problem will correspond to actual time steps [t0, (t0+tf)/4, tf], with tf varying at each iteration. An input that assumes a value for the free tf, such as [0, 0.1, 0.15], will correspond to [t0, (t0+tf)*2/3, tf] and will give the same grid if tf=0.15.

When times are fixed, the time steps stay the same at each iteration, and a small performance optimization would be to store the steps, instead of recomputing them. An indicator has_fixed_times(ocp) could be useful there. Note that giving either a grid in [t0,tf] or a normalized one will be equivalent, which is why I kept the time_grid name without mentioning the normalized aspect.

[PierreMartinon]

Some examples in https://github.com/control-toolbox/CTDirect.jl/blob/main/test/test_grid.jl