[General] Build an OCP solution

[ocots]

@PierreMartinon @jbcaillau In

CTDirect.jl/src/solution.jl

Lines 108 to 116 in 2922f2d

	function build_OCP_solution(
	docp;
	primal,
	dual=nothing,
	mult_LB=nothing,
	mult_UB=nothing,
	nlp_model=ADNLPBackend(),
	docp_solution,
	)

the primal and dual arguments are redundant with docp_solution. Besides, docp_solution is much a NLP solution than a DOCP solution. Why a keyword argument?

See the other comment...

[ocots]

The two methods

CTDirect.jl/src/solution.jl

Line 9 in 2922f2d

function build_OCP_solution(docp, docp_solution; nlp_model=ADNLPBackend())

and

CTDirect.jl/src/solution.jl

Lines 108 to 116 in 2922f2d

	function build_OCP_solution(
	docp;
	primal,
	dual=nothing,
	mult_LB=nothing,
	mult_UB=nothing,
	nlp_model=ADNLPBackend(),
	docp_solution,
	)

are different but it seems that we only need one from a NLP-solution. We need the docp to retrieve data, getters, etc.

function build_ocp_solution(docp::DOCP, nlp_solution::SolverCore.AbstractExecutionStats)

Actually, the model backend nlp_model is not really required. For ExaBackend we have

getter = docp.exa_getter

We simply need to have

getter = docp.getter
o = getter(nlp_solution; val=:objective)
X = getter(nlp_solution; val=:state)
...

Note

The getter depends on the pair (model, solver). Actually, solvers from JuliaSmoothOptimizers return a GenericExecutionStats <: AbstractExecutionStats (which should be the type of nlp_solution in that case), see NLPModelsIpopt.ipopt for instance. The solver MadNLP returns also a subtype of AbstractExecutionStats, which is MadNLPExecutionStats.

Note

In CTDirect, we only have SolverCore.AbstractExecutionStats as NLP-solution, so we just need to define the getter when building the nlp, assuming that we will build the OCP-solution from a solution of this type.

Note

In OptimalControlProblems, we will want to test different solvers and then rebuild an OCP solution. For the moment, I use only NLPModelsIpopt.ipopt which again returns a SolverCore.AbstractExecutionStats.

Example of getter from ExaModels:

solution(result::SolverCore.AbstractExecutionStats, x::Var{I}) where {I} =
    return result.solution[x.i]

We could imagine to construct an OCP-solution from a pair (model, solver) such that the solver does not return a SolverCore.AbstractExecutionStats. In that case, we could have another method:

function build_ocp_solution(docp::DOCP, nlp_solution, getter::Function)

[ocots]

In conclusion we need:

function build_ocp_solution(docp::DOCP, nlp_solution::SolverCore.AbstractExecutionStats)
function build_ocp_solution(docp::DOCP, nlp_solution, getter::Function)

And

getter = docp.getter
o = getter(nlp_solution; val=:objective)
X = getter(nlp_solution; val=:state)
...

Note

We must avoid any acces via a field to the NLP-Solution: nlp_solution.field.

[PierreMartinon]

@ocots @jbcaillau, agreed

As you deduced, docp_solution was added (by a mysterious individual I shall not name except by his initials J and B) to the second method to be able to use the getters from ExaModels.

This is a temporary fix, and the whole ExaModel part needs to be refactored for better integration (cf discretizations, initial guess, solution building).

As for the two methods, the first one, as you say, takes a NLPModel type solution from an ADNLPModel DOCP. The second one was originally for the other cases, and takes more basic arguments such as arrays for the primal and dual variables. This one has been adapted for ExaModel, and needs to be cleaned up. We could officially make it the ExaModel version and drop the separate arrays arguments. The only drawback I see is that we would lose the ability to build an OCP solution from a generic array formatted solution (primal and dual variables). However we don't really use that in practice, and it could be re-added later.

[ocots]

I think that with

function build_ocp_solution(docp::DOCP, nlp_solution, getter::Function)

you will have all the possibilities. Just that the getter is more high-level than simply giving the primals and the duals. With the two methods of build_ocp_solution, we do not need to know how the variables are stored in the model.

[jbcaillau]

I think that with

function build_ocp_solution(docp::DOCP, nlp_solution, getter::Function)
you will have all the possibilities. Just that the getter is more high-level than simply giving the primals and the duals. With the two methods of build_ocp_solution, we do not need to know how the variables are stored in the model.

indeed, it is a good idea to use getters from the modeller to retrieve information on the solution for a posteriori treatment. although it is true that, in the case of ADNLP, @PierreMartinon actually explicitly builds the vector (not using that much CTModels as a modeller).

[PierreMartinon]

I agreed that the older code that parses the data for ADNLP should be rewritten as getters, so we would have a (more) unified syntax !