[Knitro 12.3] Error when setting variable bound to Inf

[ferrolho]

Hi, François! :) Today I upgraded from Knitro 12.2.2 to Knitro 12.3.0, and I bumped into this error:

ERROR: The lower bound specified for variable index 0 is undefined.

The problem was that I was defining the lower and upper bounds of some decision variables with -Inf and +Inf. I stopped defining the bounds for variables which do not have bounds, and things are now working. Anyway, I decided to create this issue because I wanted to ask you: do you think we should have a safeguard in Knitro.jl for when the user tries to set bounds to infinity? In numerical optimisation, I believe it is bad practice to define any bounds at all when variables or constraints are unbounded, right?

Additional info: I looked at the diff since v0.9.2 (v0.9.2...v0.9.3) but I didn't spot anything that could be related, so I guess it was some internal change in Knitro which is now triggering this error if the bounds are Inf. Curiously, I compared the outputs of Knitro 12.2.2 and 12.3.0 during the optimisation, and under 'Problem Characteristics' I can see that the actual number of bounds for my decision variables is exactly the same, so I guess Knitro was silently dealing with this prior to 12.3 by not defining bounds at all when I set them to Inf.

[odow]

Do you have a reproducible example of this?

[odow]

I've tried various things to reproduce this without success, so closing as non-reproducible (or perhaps fixed).

Please re-open if you have a reproducible example.

[ferrolho]

FYI, I did not ignore your comment, Oscar; it's just that I'm having issues with my KNITRO licence for a few days now (machine ID is picking up a different network card), and without a licence it's hard to work on a MWE. Anyway, I could've dropped a message here saying that I was looking into it, so apologies for that.

[odow]

Was it with JuMP? MOI? Or the pure Knitro API?

[ferrolho]

It was while using the Knitro API directly.

Here's part of a commit diff on a private repos (from 28 Jan 2021), where I added an !isinf check to work around the issue:

[odow]

I'm going to mark this as won't-fix. In general, calling the C API is on the user to get right, and it's my experience with other wrappers that introducing additional checks into the C wrapper is just a recipe for problems.

I already think the C_wrapper.jl is too heavy, but removing it is probably too breaking: https://github.com/jump-dev/KNITRO.jl/blob/master/src/C_wrapper.jl

Gurobi/CPLEX/etc all have a raw C API + MathOptInterface, with no layer in between. Adding that layer just leads to confusion.

[ferrolho]

In general, calling the C API is on the user to get right, and it's my experience with other wrappers that introducing additional checks into the C wrapper is just a recipe for problems.

Fair enough! Thanks, @odow.