Initial point is incorrectly classified as infeasible about scip.jl

[rschwarz]

Your observation about LAPACK and IPOPT is correct. However, whether you compile SCIP with IPOPT support is independent to SCIP.jl. Our instructions do not use IPOPT, but you can, by setting IPOPT=TRUE in the make call. SCIP.jl should work just the same.

Whether or not this has anything to do with your solution candidate, I can not tell. I know that we (in SCIP.jl) do not yet support incomplete initial solutions, where only values for some of the variables are given. But in your example, some solution is apparently set, and tested.

[adowling2]

@leethargo Thank you for the quick reply.

I compiled with IPOPT=true.

Looking closer at the output

  [nonlinear] <nonlin_obj>: (1 * <_var0_>)-1<_var4_>[C]  <= 0;
violation: right hand side is violated by 5 (scaled: 5)
all 1 solutions given by solution candidate storage are infeasible

from my example, I noticed the variables go from var0 to var4. However, there are only 4 variables in the example. You mentioned that SCIP.jl does not support incomplete solution candidates. Is it possible that SCIP.jl is adding an extra dummy variable which happens to be uninitialized?

[rschwarz]

I think the (lack of support for) incomplete solution candidates is not the issue.

If I look at the violated constraint, it looks like this constraint is created automatically (together with the variable _var4_ during the process of transforming the nonlinear constraints for SCIP. Unfortunately, the auxiliary variable _var4_ will apparently take the value 0 for the solution candidate, which is infeasible.

So, this is a bug in either SCIP.jl or CSIP.

[rschwarz]

Sorry, this does not look like an easy fix.

[fserra]

yes, somehow, we need to evaluate the objective function at the point given and then assign the extra variable to that value