loadProblem() with a single function call about scip HOT 2 OPEN

Afaik there is no algebraic modelling (or let's say matrix-based modelling) available in SCIP, meaning: there is no way to define a vector / batch of variables and there is no way to define a vector / batch of constraints defined by a constraint coeff-matrix and a constraint rhs-vector.
Each var and each constraint introduced needs an explicit call to do that.

That being said, i don't see the issue.

Targeting this kind of low-lvl algebraic structure (i'm having Highs in mind which i once filled with some parent which also filled or-tools' PDLP) sounds relatively straightforward to me:

• One loop over your coeff-matrix columns for introducing variables
• One loop over your coeff-matrix rows for introducing linear-constraints (SCIP actually also provides range-constraints out of the box)

I would guess that's < 100 lines of code. Maybe even < 50 if one would store the algebraic model in something like Eigen. Don't forget the necessary memory-management (SCIPfree...)

Don't you agree, that a 50-100 loc wrapper external_to_scip(...) is a small investment?

One more remark:

• There might also be a way to just write out lp/mps in one of your other tools and read that into SCIP (even through streams/pipes if "real" files make you nervous)

One more opinion:

• I think the most interesting part of SCIP (where it even surpasses all commercial solvers and other alternatives) is it's plugin system and what you can do with it:
  • One might argue, that the information-loss you experienced by importing the low-lvl model instead of the high-lvl model is problematic
    • It's not uncommon in my code, that SCIP types are embedded into some high-lvl C++ types like EigenMatrix or boost::graph which (depending on your problem) allows lots of powerful things!

from scip.

Hi, you are correct that there is no such matrix-based problem creation function in SCIP. I agree that this would be a nice convenience feature. It could be an addition to the interface of cons_linear. I don't think we are going to implement that ourselves, but we would welcome and support a PR! (The solution is pretty much a combination of for loops as described by @sschnug .)

from scip.