Semi continuous variable

[datadrivensupplychain]

Can this be made an option for declaring variables? I know lpsolve and gurobi both support semi-continuous variables.

[dirkschumacher]

Yeah, seems like a good idea. Not sure if ROI supports it though.

[datadrivensupplychain]

Thanks, I hope it's possible. I'm using Gurobi extensively with ompr now, and lack of semi continuous variables is one of the few gaps I see in capabilities (besides the limitations to MILP only)

Also is there any way to provide some financial support for the ompr project? I'm certainly gaining financially by using ompr in my consulting work, I'd like to help keep it going.

[sbmack]

Also is there any way to provide some financial support for the ompr project? I'm certainly gaining financially by using ompr in my consulting work, I'd like to help keep it going.

I did a compare and compare and contrast between a Gurobi v. ompr R formulation in an earlier post.

A few years ago I suggested to the Gurobi people who oversaw their R platform that they consider using ompr as their R interface and update it with additional functionality to make it more robust. (Given that ompr is a side-project for Dirk). My hope was that Gurobi would make its enhanced ompr version freely available and solver independent. Unfortunately, after a response of mild curiousity from Gurobi, nothing became of it.

[datadrivensupplychain]

Yes it seems like the use of ompr with Gurobi is pretty unknown to Gurobi (or, at least, their tech support). But I personally am running models with multiple millions of variables and tens of thousands of constraints using ompr and Gurobi with quite good performance. And once I figured out how to exploit MILPModel to quickly add hundreds of constraints, model builds became very fast.

…

On Mon, Sep 5, 2022, 10:54 AM SteveM ***@***.***> wrote: Also is there any way to provide some financial support for the ompr project? I'm certainly gaining financially by using ompr in my consulting work, I'd like to help keep it going. I did a compare and compare and contrast between a Gurobi v. ompr R formulation in an earlier post <#421 (comment)> . A few years ago I suggested to the Gurobi people who oversaw their R platform that they consider using ompr as their R interface and update it with additional functionality to make it more robust. (Given that ompr is a side-project for Dirk). My hope was that Gurobi would make its enhanced ompr version freely available and solver independent. Unfortunately, after a response of mild curiousity from Gurobi, nothing became of it. — Reply to this email directly, view it on GitHub <#424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASKSE67EL3GFKZKA6TV5SP3V4YJS3ANCNFSM5VMVE7MA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dirkschumacher]

HiGHS also supports semi continuous/integer variable. We should really do that.

[datadrivensupplychain]

@dirkschumacher So with ompr.highs, do you no longer need ROI to solve using ompr? I saw on LinkedIn that you and Florian had authored an R package for HiGHS, but I assumed (and made a comment) that you needed to write ROI.plugin.highs to use HiGHS as a solver.

TBH one of the few big drawbacks I see with ompr is having to track down the ROI.plugin.solvername package for the solver you want. (Installing ROI.plugin.gurobi was a feat I don't want to repeat). If that's not necessary in the future, that will be a MAJOR win for ompr as an R-based alternative to Pyomo or PuLP.

[dirkschumacher]

It has always been possible to use other solvers apart from ROI. You just need to write your own glue code connecting the ompr model to an ompr solution. If you look at the HiGHS interface, it is actually not a lot of work: https://github.com/dirkschumacher/ompr.highs/blob/c0e0ce60753a41956e31de71c9e9da2ceaccee3f/R/highs.R#L26-L84

Substituting the call to highs by the call to the Gurobi R package would probably give you 95% of a Gurobi solver for ompr. A solver really is just a plain function mapping a model to a solution