SolverInfos

[ocots]

We should pass docp_solution to SolverInfos, no?

CTDirect.jl/src/solution.jl

Line 119 in 21c4dff

iterations, constraints_violation, message, status, successful = SolverInfos()

[PierreMartinon]

This method is a dummy one, used in the build_OCP_solution method that was originally supposed to take individual arrays for the primal, dual and bounds multipliers. I will progressively rewrite this part for a better integration of ExaModels.

First, the two primal/dual parse functions will be replaced by individual getters, since ExaModels works this way. This should allow for a much more unified code in the solution building.

[jbcaillau]

@PierreMartinon on the same line (after kyoto business, of course 🤗): print_level should be uniform for all solvers; maybe

• using a new keyword not to break the interface and leave the possibility to fine tune the level solver by solver
• having this new keyword with essentially two options: silent or not

[ocots]

@PierreMartinon on the same line (after kyoto business, of course 🤗): print_level should be uniform for all solvers; maybe

• using a new keyword not to break the interface and leave the possibility to fine tune the level solver by solver
• having this new keyword with essentially two options: silent or not

I would say that it would be great if we could either pass an option from the solver (int or MadNLP....) or a something which works for both. We could replace MadNLP types to Symbols and map the symbols to them or integer for Ipopt.

Note that we have already the keyword display::Bool that has two modes: silent or not.

[jbcaillau]

@PierreMartinon on the same line (after kyoto business, of course 🤗): print_level should be uniform for all solvers; maybe

Note that we have already the keyword display::Bool that has two modes: silent or not.

✅ @ocots display does exactly what i had in mind: all set!