Roadmap Sprint 6 and more - February 2023

[ocots]

Travail pour PM-JG

• compléter la liste des getters
• récupérer les multiplicateurs des contraintes
• time, state, control, adjoint, multipliers on the same grid
• solution plot
• gestion du creux (message à Alexis Montoison)
• schémas RK

Travail pour JBC-OC

• Scalar / vector control / state : sur le fonctionnel, passer en vectoriel sur le contrôle
• gestion des contraintes (par ordre de priorité) en fonctionnel : boites, état pur, linéaire, autonome/non-autonome : Issue 63, Issue 64
• pure vs. mixed state constraint: encapsulate the type in the function returned by a constraint call to be able to design properly the Hamiltonian (needs to call with x only, or (x,u) depending on the type)

[ocots]

We can continue this:

• standardize the options of direct and direct shooting solvers. For instance, replace grid_size by grid in direct solve.
• standardize the getters of solutions. I have added an abstract type returning errors if the getter is not implemented for a concrete struct.
• add print callback to the direct method in coherence with the direct shooting method. 
• make a common plot working for direct and direct shooting methods.
• update plot of flows, see issue 81
• handle scalar / vectorial state / control. Voir issue 68
• add box constraints.
• mixed / state / control constraints in place of mixed / control, see issue 63
• fix print ocp, see issue 25
• make modules to test if it improves compilation: no improvement. Need to make some packages.

[ocots]

For the grid we cannot standardize for the moment since the direct shooting method consider only fixed tf contrary to the direct method.

[PierreMartinon]

Not sure I understand the problem. Is it a question of type (parameter vs variable) ?

[ocots]

Je réponds en français pour aller plus vite. Je voulais avoir la même option pour le tir direct et la méthode directe, pour le choix de la grille vs le choix de la taille de la grille. Dans le tir direct, je fais passer la grille directement mais donner juste la taille peut aussi être sympa pour laisser le solveur créer la grille uniforme. Dans ton cas, c'est le contraire, tu donnes la taille. Donc pour harmoniser, ce serait bien de pouvoir faire les deux mais pour le moment tu ne gères pas la grille directement. Donc je me suis dis que j'allais changer ça mais dans le cas où le temps final est libre, ce n'est pas si intuitif que ça que de fournir la grille. Donc je reviens à mon point de départ qui est : quel choix fait-on si l'on veut harmoniser ? Veut-on vraiment harmoniser cette option ?

[ocots]

Not so simple to change the callback for ipopt. We will see later.

[PierreMartinon]

• Done: getters for components of the direct solution, including info suc as objective, constraint violation, and solver iterations.
• Done: retrieve constraints multipliers. Todo: plot the state constraints with their multipliers. We could do a first test on the goddard example by plotting only the speed constraint.
• Done: a first very crude version of getting all state / costate / control variables on the same time grid, which takes [t_0, ..., t_f] as grid and simply duplicates the last value of the costate. Todo: add more elaborate versions, with an option to select the one to use. The option would be passed to the accessor, ie state/adjoint/control(sol, [export_option=default]).

[ocots]

Question: would-it be nice to return functions of time instead of points on a grid? See the library of problems I have started to code. Here is an example where I give the solution as functions of time. To plot the solution, there is a grid inside the solution, see here. We can imagine to add the possibility to change the grid for the plot with an option. Note that for this example I have the analytical solution. However, in general, if we solve a problem on a given grid and then if we use linear interpolation, then for the plot, it is the same between plotting the points on the grid and plotting the interpolated functions of time on the grid.

[ocots]

This has the advantage to return a value for any time.

[jbcaillau]

Do we actually need to make a choice? The solution structure may provide both things, depending on the way it is used/called.

[ocots]

It would be nice to have a common plot for all the methods (direct, direct shooting...). One way to have this is to have a common struct for the solution. Hence, we have to make a choice on the interne configuration of the structure. For the moment, the direct method returns Matrix{<:Real} type whereas the direct shooting method returns Vector{<:Vector{<:Real}}. This is quite annoying.

We need examples to have an idea about how we could interact with the solution. For instance, with DifferentialEquations when we have an ODE solution denoted sol, then, we can get access to the discretized integration steps by sol.u. We can also get access to the value at time t by sol(t) I think. In our case, we have state, adjoint, costate... What do we want to do?

x = sol.x
u = sol.u

or

x = sol.state
u = sol.control

Then, do we prefer x(t) or x[i]? I think we cannot have both. We could imagine (I don't really like it):

x = sol.state(:function) # or :continuous
x(t)
# or
u = sol.control(:discretized)
u[i]

[jbcaillau]

state rather than x. can’t we have both x[i] and x(t) in julia? otherwise what you suggest could be fine. and yes, let’s keep on working on use cases.

[jbcaillau]

About plots, trick to plot directly (and only) to a file:

using Plots
ENV["GKSwstype"]="nul"
plot(rand(100,1))
savefig("test.png")

See this post

[jbcaillau]

[ocots]

Many interesting things here: https://juliadynamics.github.io/DynamicalSystems.jl/latest/dynamicalsystems_interactive/

[jbcaillau]

👍🏽 and with Documenter.jl