Parameters with initial NaN values seem to poison the model

[rdeits]

Creating a model with parameters whose initial values are NaN seems to break the model, even if those parameters are changed to non-NaN before any call to solve!. For example:

# Set up the model
m = Model(OSQP.Optimizer())

# Create an externally-controlled value. This is initially NaN, but
# we will set it to non-NaN later
outer_value = Ref(NaN)

# Create a parameter which just reads from our outer value
param = Parameter(m) do
    outer_value[]
end

# Constrain that the variable x == param. At this point, outer_value[] == NaN
x = Variable(m)
@constraint m x == param

# Fix our outer_value so that it is non-NaN
outer_value[] = 1.0

# Solve. All the parameters are now non-NaN, but the solver still fails:
solve!(m)

objectivevalue(m)

gives an objective value of NaN.

Moving the outer_value[] = 1.0 to before the call to @constraint fixes the problem, but shouldn't be necessary as far as I know.

[tkoolen]

So the same thing also happens for Gurobi, and it looks like both OSQP.jl and LinQuadOptInterface.jl have essentially the same bug. The problem is that a difference between the current and new value of the right-hand side is computed, so if the old value is NaN you run into trouble.

For LQOI:

https://github.com/JuliaOpt/LinQuadOptInterface.jl/blob/7f4d09bf834f1ba3e2938397dbfae5c7108fe281/src/constraints/scalaraffine.jl#L264

For OSQP:

https://github.com/oxfordcontrol/OSQP.jl/blob/8dd46b5a7c8955ae41cf8464295825801946e939/src/MOI_wrapper.jl#L617