Binary variable <= Binary matrix: Error in constraint$lhs - constraint$rhs : non-numeric argument to binary operator

[datadrivensupplychain]

I am building a MILPModel where the primary decision variables are binary, x[i,j]. Depending upon the i,j pair, I may want to force x[i,j] to 0 instead of giving the model the choice of 0 or 1. I have a static matrix, allowed_binary, that is i rows and j columns, with value of 0 if x[i,j] must be 0, and a value of 1 if x[i,j] can be 0 or 1. I made a very simple constraint:

add_constraint(x[i,j] <= allowed_binary[i,j], i=1:10, j = 1:20)

This constraint is accepted by ompr with a MIPModel but when I add it in a MILPModel, I get the error Error in constraint$lhs - constraint$rhs : non-numeric argument to binary operator. Is this because of how MILPModel handles multidimensional decision variables? I could probably form my decision variables x to be along a single vector if necessary.

[sbmack]

Is this because of how MILPModel handles multidimensional decision variables? I could probably form my decision variables x to be along a single vector if necessary.

Right. MILPModel was formulated with significant performance improvement over the original MIPModel. But using arrays in MILPModel constraints requires the use of the colwise auxiliary function which users found not intuitive. Dirk has since updated MIPModel incorporating the performance improvements of MILPModel while maintaining the formulation elements of the original MIPModel.

So it is my impression now that the updated MIPModel supercedes MILPModel. So your MIPModel version is what you should use.

[datadrivensupplychain]

OK, I'm actually (sorta) used to using colwise now, so if that's they key then I'll use that. Good to hear that MIPModel now has the performance benefits of MILPModel. I've been using MILPModel exclusively for a couple years now because of the speed of the model build, and just had to accept that the syntax was an acquired taste.

[sbmack]

BTW, you may want to install the development versions of ompr, ompr.roi to ensure that the latest functionality is being accessed by your MIPModel formulation:

remotes::install_github("dirkschumacher/ompr")
remotes::install_github("dirkschumacher/ompr.roi")

[datadrivensupplychain]

Thanks, I'll try that. Right now I'm using the latest CRAN versions of both ompr and ompr.roi. I'm also using some random version of ROI.plugin.gurobi I was able to successfully install