[Doc] Relecture de la documentation
Cette issue a pour objectif de recenser les modifications à apporter au code suite à la relecture de la documentation.
Basic exemple
Exporting and importing the solution
The codes don't work 👍 using JSON3
julia> export_ocp_solution(sol; filename="my_solution", format=:JSON) ERROR: ExtensionError. Please make: julia> using JLD2, JSON3 Stacktrace: [1] export_ocp_solution(args::OptimalControlSolution; kwargs::@Kwargs{filename::String, format::Symbol}) ...
Basic exemple
Exporting and importing the solution
The codes don't work 👍 using JSON3
julia> export_ocp_solution(sol; filename="my_solution", format=:JSON) ERROR: ExtensionError. Please make: julia> using JLD2, JSON3 Stacktrace: [1] export_ocp_solution(args::OptimalControlSolution; kwargs::@kwargs{filename::String, format::Symbol}) ...
@joseph-gergaud Have you updated the packages? The message
Please make: julia> using JLD2, JSON3
is weird since now JLD2 and JSON3 are split:
https://github.com/control-toolbox/CTModels.jl/blob/2e4b2caaa49b093407f533b8771101466ba62900/src/CTModels.jl#L133-L153
@joseph-gergaud @ocots better if we contain this example in a single doc page, not to block the new release for sth that is rather a detail (and most probably used by very few)
Define a problem
- The user don’t use the following syntax :( $v ∈ R^$q, variable ) :( $v ∈ R , variable )
So, why do we mention it ?
Constraints Exemple for me there is 4 linear boundary constraints and one nonlinear one-sided not two-sided) constraint
: • two linear boundary constraints, • one linear variable constraint, • one linear state constraint, • one (two-sided) nonlinear control constraint.
Define a problem
- The user don’t use the following syntax :( $v ∈ R^$q, variable ) :( $v ∈ R , variable )
So, why do we mention it ?
Constraints Exemple for me there is 4 linear boundary constraints and one nonlinear one-sided not two-sided) constraint
: • two linear boundary constraints, • one linear variable constraint, • one linear state constraint, • one (two-sided) nonlinear control constraint.
Il y a bien 2 boundary pour x(0) et x(tf), 1 linéaire sur la variable tf, 1 linéaire sur x(t) et 1 non linéaire sur u.
Par contre elle était bien "one-sided", j'ai modifié ça : https://github.com/control-toolbox/OptimalControl.jl/pull/569.
On a deux fois
time : t, ....
julia> @def damped_integrator begin
tf ∈ R, variable
t ∈ [0, tf], time
x = (q, v) ∈ R², state
u ∈ R, control
q̇ = v(t)
v̇ = u(t) - c(t)
ẋ(t) == [q̇, v̇]
end true;
variable: tf, dim: 1
time: t, initial time: 0, final time: var"tf##616"[1]
state: x, dim: 2
control: u, dim: 1
alias: q̇ = (x[2])(t)
alias: v̇ = (var"u##617"[1])(t) - c(t)
dynamics: ∂(x)(t) == [(x[2])(t), (var"u##617"[1])(t) - c(t)]
variable: tf, dim: 1
time: t, initial time: 0, final time: var"tf##632"[1]
state: x, dim: 2
control: u, dim: 1
alias: q̇ = (x[2])(t)
alias: v̇ = (var"u##635"[1])(t) - c(t)
dynamics: ∂(x)(t) == [(x[2])(t), (var"u##635"[1])(t) - c(t)]
ERROR: UnauthorizedCall: the objective must be set before building the model.
On a deux fois
time : t, .... julia> @def damped_integrator begin tf ∈ R, variable t ∈ [0, tf], time x = (q, v) ∈ R², state u ∈ R, control q̇ = v(t) v̇ = u(t) - c(t) ẋ(t) == [q̇, v̇] end true; variable: tf, dim: 1 time: t, initial time: 0, final time: var"tf##616"[1] state: x, dim: 2 control: u, dim: 1 alias: q̇ = (x[2])(t) alias: v̇ = (var"u##617"[1])(t) - c(t) dynamics: ∂(x)(t) == [(x[2])(t), (var"u##617"[1])(t) - c(t)] variable: tf, dim: 1 time: t, initial time: 0, final time: var"tf##632"[1] state: x, dim: 2 control: u, dim: 1 alias: q̇ = (x[2])(t) alias: v̇ = (var"u##635"[1])(t) - c(t) dynamics: ∂(x)(t) == [(x[2])(t), (var"u##635"[1])(t) - c(t)] ERROR: UnauthorizedCall: the objective must be set before building the model.
Celle-là, elle pour @jbcaillau je pense. CTParser ?
@joseph-gergaud what is the issue? (apart from the fact that the cost is not defined.)
@joseph-gergaud what is the issue? (apart from the fact that the cost is not defined.)
The output is printed twice.
Main functionalitie pseudo-Hamiltonian $H(x,p,u) = p_qq + p_vv + ...$ -> $H(x,p,u) = p_qv + p_vu + ...$
Pour le problème de Goddard voici le message d'erreur que j'ai (sous Macbook puce Apple M3 Pro). Je pense que c'"st le même problème qu'Olivier, mais il faudrait peut-être le signaler.
indirect_sol = fsolve(nle!, jnle!, ξ, show_trace=true) Iter f(x) inf-norm Step 2-norm Step time
ERROR: cfunction: closures are not supported on this platform
Stacktrace:
[1] hybrj(f!::var"#27#28", g!::var"#29#30", x0::Vector{…}, xtol::Float64, show_trace::Bool, tracing::Bool, maxit::Int64; _n::Int64, ml::Int64, mu::Int64, maxfev::Int64, epsfcn::Float64, diag::Vector{…}, mode::Int64, factor::Float64, nprint::Int64, lr::Int32)
@ MINPACK ~/.julia/packages/MINPACK/eU7Uf/src/wrappers.jl:152
[2] hybrj(f!::Function, g!::Function, x0::Vector{Float64}, xtol::Float64, show_trace::Bool, tracing::Bool, maxit::Int64)
@ MINPACK ~/.julia/packages/MINPACK/eU7Uf/src/wrappers.jl:102
[3] #fsolve#2
@ ~/.julia/packages/MINPACK/eU7Uf/src/MINPACK.jl:151 [inlined]
[4] fsolve
@ ~/.julia/packages/MINPACK/eU7Uf/src/MINPACK.jl:146 [inlined]
[5] top-level scope
@ REPL[1]:1
Some type information was truncated. Use show(err) to see complete types.
julia>
Pour le problème de Goddard voici le message d'erreur que j'ai (sous Macbook puce Apple M3 Pro). Je pense que c'"st le même problème qu'Olivier, mais il faudrait peut-être le signaler.
indirect_sol = fsolve(nle!, jnle!, ξ, show_trace=true) Iter f(x) inf-norm Step 2-norm Step time
ERROR: cfunction: closures are not supported on this platform Stacktrace: [1] hybrj(f!::var"#27#28", g!::var"#29#30", x0::Vector{…}, xtol::Float64, show_trace::Bool, tracing::Bool, maxit::Int64; _n::Int64, ml::Int64, mu::Int64, maxfev::Int64, epsfcn::Float64, diag::Vector{…}, mode::Int64, factor::Float64, nprint::Int64, lr::Int32) @ MINPACK ~/.julia/packages/MINPACK/eU7Uf/src/wrappers.jl:152 [2] hybrj(f!::Function, g!::Function, x0::Vector{Float64}, xtol::Float64, show_trace::Bool, tracing::Bool, maxit::Int64) @ MINPACK ~/.julia/packages/MINPACK/eU7Uf/src/wrappers.jl:102 [3] #fsolve#2 @ ~/.julia/packages/MINPACK/eU7Uf/src/MINPACK.jl:151 [inlined] [4] fsolve @ ~/.julia/packages/MINPACK/eU7Uf/src/MINPACK.jl:146 [inlined] [5] top-level scope @ REPL[1]:1 Some type information was truncated. Use
show(err)to see complete types.julia>
@joseph-gergaud je suppose, en effet : pas de MINPACK sur mac. @ocots tu confirmes ?
Yep c'est pareil pour moi.
@joseph-gergaud @ocots OK
sur ce point :
- on avait la comparaison
MINPACK.fsolvevs. les deux autres solveurs sur une précédente version, assez grosse différence en temps de calcul et en allocations (négligeables ici, cela dit), d'où ma préférence pour MINPACK - le truc important néanmoins, c'est la convergence (là encore je suppose que MINPACK est meilleur mais c'est à tester plus avant
- mon point de vue sur les OS : je suis favorable à ne gérer que linux (CPU + GPU) pour éviter les ennuis ; si on a de la demande + qqun d'autre que nous pour gérer autre chose, à revoir
- sur indirect + solve : après une grosse passe sur le direct cette année 2024-25 (et la v1.10), l'idée est de remettre l'indirect (CTFlow) à plat en, 2025-26 avec la délégation d'Olivier
- dès à présent : tests à refaire après https://github.com/control-toolbox/CTFlows.jl/issues/42#issuecomment-2880597250
Dans Compute Flows, Flow API
- C'est quoi le l dans h(t, x, p, l) : This method builds a numerical integrator that simulates the evolution of a Hamiltonian system given a Hamiltonian function h(t, x, p, l) or h(x, p).
- Dans l'exemple suivant julia> hv(t, x, p, l) = (∇ₚH, -∇ₓH) julia> flow = CTFlows.Flow(CTFlows.HamiltonianVectorField(hv)) julia> xf, pf = flow(0.0, x0, p0, 1.0, l) On a pas le H avant
- Je metttrais Flow API après From Hamiltonians and others ou dans les API
https://control-toolbox.org/Tutorials.jl/stable/tutorial-goddard.html#tutorial-goddard-structure
Dans la définition des crochets H_{001} et H_{101} on a H_0 et H_1. H_1 est donné au dessus dans le code et H_0 dans le code de dessous. Il faut peut-être définir H_0 et H_1 dans le texte.
https://control-toolbox.org/OptimalControl.jl/dev/jlesc17.html#Discretise-then-solve-strategy-(aka-direct-methods)
Il n'y a pas les codes, c'est normal ?
https://control-toolbox.org/Tutorials.jl/stable/tutorial-lqr.html#Limitations:-using-matrix-formulation
Je ne comprends pas pourquoi on ne peut utiliser cette formulation.
Ne faudrait-il pas mettre cette limitation dans la documentation : https://control-toolbox.org/OptimalControl.jl/stable/tutorial-abstract.html#tutorial-abstract-syntax
https://control-toolbox.org/Tutorials.jl/stable/tutorial-lqr.html#Limitations:-using-matrix-formulation
Je ne comprends pas pourquoi on ne peut utiliser cette formulation.
Ne faudrait-il pas mettre cette limitation dans la documentation : https://control-toolbox.org/OptimalControl.jl/stable/tutorial-abstract.html#tutorial-abstract-syntax
@joseph-gergaud on peut l'utiliser : il y a un pb avec la diff. auto. ensuite si on laisse l'option par défaut, exactement comme expliqué ici https://control-toolbox.org/Tutorials.jl/stable/tutorial-lqr.html#Limitations:-using-matrix-formulation
c'est un peu inapproprié de parler de "limitation", c'est plutôt une "know issue" qui n'est pas de notre fait.
@ocots https://github.com/control-toolbox/Tutorials.jl/issues/31