Add MOI.LagrangeMultiplier attribute

[odow]

Closes #2887

x-ref jump-dev/Ipopt.jl#521

Questions:

• should we have get_fallback?

[Robbybp]

Is there any reason this is LagrangeMultipliers (plural)? Just seems inconsistent with ConstraintDual. Should there also be a LagrangeMutlipliersStart attribute for initializing these multipliers?

[odow]

I was wondering about the start. And yes, we could go with singular.

[francis-biocurie]

Warm start is a nice-to-have but less important IMO, since we can always do the conversion manually with $\mu^\top J(x)$, which is not the case in the opposite direction

[odow]

Nah, we've added an explicit warm-start for \mu, not for y = \\mu^top J(x). We can't guarantee we can get a start for \mu based on a start for y.

[blegat]

If we only have solvers for which the attribute is easy to implement, I'd rather not have get_fallback. The attributes that have a fallback are the ones for which if we had to implement it in the solvers we would need to copy paste the code of the fallback. Here, the solver have more information than the fallback so they can directly give these multipliers.

[odow]

Okay, I removed the fallback.

[franckgaga]

@odow, just to be sure, I assume that's it not possible right now with MOI v1.48 to fetch the optimal Langrange multiplier on a real problem solved by Ipopt.jl (i.e. the attribute will need to be implemented in Ipopt.jl package first) ?

[odow]

Give me a minute! Yes, we needed to release v1.48 first. Then I need to make changes to Ipopt.jl and KNITRO.jl. Only after they are released will you be able to call get_attribute(model, MOI.LagrangeMultiplier(), c)

[franckgaga]

Yeah no problem, no hurries! I was just lost in the "attribute" concept (if it's somethings that should just work without any changes required on NLP solver side or not).

[odow]

MOI can be confusing. Its main job is to be a thin API layer that just defines the attributes. This lets external Julia packages implement multiple dispatch without type piracy. In any other Julia community we could have created MathOptInterfaceBase.jl.

But there's also a bunch of other heavy lifting code in MOI for doing related things, so it can be hard to know from the outside what are new API definitions that need work in other packages, and what are new features being added to MOI that are instantly accessible from every solver package.