Return cons, grad, hess evaluations at the solution

[juliasmoothoptimizers]

Return cons, grad, hess evaluations at the solution

[tmigot]

If we have a KnitroSolver, then we could store kc in it, and write a finalizer. That would allow users to perform solves of the same problem from a different starting point, etc.

Great, I will make it concrete in a PR.

[dpo]

Could you add a link to the documentation describing how to retrieve those values?

[tmigot]

Here is the link to the documentation Reading model/solution properties

There is no further doc for KNITRO.jl, but the useful functions can be found in src/kn_attributes.jl.

[dpo]

Could we return the kc object in stats so the user can query those if they want? I don’t think we should store entire Hessians or Jacobians in stats...

[tmigot]

Agreed. I think we can pass the kc object, the only drawback is that the user has to use KNITRO.KN_free(kc) (which is done right now at the end of the knitro call) to "finalize" the model similar to a CUTEstModel.

Another alternative would use kwargs so that the user asks from the solver call for the returned values.

[dpo]

Yes, that’s better. Let’s make it optional. But does that mean we need a KnitroSolver to preallocate?

[tmigot]

Yes, a KnitroSolver would be a clean way to do it. So, the user needs to specify the evals from the initialization of the KnitroSolver.

[dpo]

Yes. There could be a check in the solver that the space has been allocated (and an error if it hasn’t).

[dpo]

If we have a KnitroSolver, then we could store kc in it, and write a finalizer. That would allow users to perform solves of the same problem from a different starting point, etc.