10
$\begingroup$

I have just started to dive into OR world on my work. Currently we are using GAMS with Gurobi but some of us have strong programming background and would like to have more programmatic approach to OR.

I have heard that without GAMS you can't get fast feedback on your model, like if constraints are impossible, model can't be solved, existence of indefinite loops etc.

So I am wondering is what are pros and cons for using directly Gurobi's Python API instead of doing modeling in GAMS?

If separating model from solver is good, does modeling frameworks in Python like Pyomo have also this model check option like GAMS? I managed to find that pyomo command line interface has check command but I have no clue what it does.

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ To add others mentioned, this and this links would be useful. $\endgroup$
    – A.Omidi
    Mar 11, 2020 at 10:29
  • $\begingroup$ For the people who are also in dilemma like I used to be, this is the outcome. Whole team was against GAMS, too awkward syntax even for old programmer like me (I had Cobol in University). Then we were for Pyomo. It is possible to find some examples, even book, nice syntax... Then we tried gurobipy and got impression that it is not so low-level and it is more powerful, although less resources for learning and no book to use. Gurobi won. $\endgroup$
    – aurelije
    May 11, 2020 at 13:06

2 Answers 2

Reset to default
8
$\begingroup$

In a production environment, I have found code APIs to be superior to modelling languages in the long run. Nowadays, we also have Pyomo so we don't even need to compromise between the two.

The subtlety is that if you use a solver's Python API your code is tied to that solver. Conversely, if you use a modelling environment (e.g. GAMS), you can seamlessly swap solvers but you are tied to the modelling environment.

Even though my personal preference is AMPL (simply because I like the product and the language), when we deploy projects we typically use Pyomo & the Octeract Reformulator API because:

  • Clients typically don't want to pay for yet another license.
  • Everything is natively in Python making integrations with data/csv etc. very easy.
  • The modelling environment is not licensed therefore the code will still work even if the client decides to switch to a different solver/environment/machine later on. They tend not to, but people like to feel reassured like that.
  • People can share the project with other people who don't have access to a licensed modelling language.

For academia on the other hand, it's a no-brainer: use software that non-academics can also access for free, otherwise no-one outside academia will ever use anything we create, and neither can we after we leave academia.

Improve this answer
$\endgroup$
2
  • 3
    $\begingroup$ I find "seamlessly swap solvers" is a truth with modifications. $\endgroup$
    – ErlingMOSEK
    Mar 11, 2020 at 11:23
  • 1
    $\begingroup$ Update after months of development: every day I am glad that we have moved from GAMS to Python API for Gurobi. The model preparation is done in Pandas so we can debug model, we have observability comparing to black box of GAMS from which we could not get even LP file. So our input is fetched as pandas series and frames, we create variables as pandas frames calling pd.DataFrame({'var_name': model.addVars(...)}, index=var_set), then expressions for constraints are done in pandas and then model.addConstraints. Output is already data frame just do df.var_name.map(lambda v: v.x).to_frame('value') $\endgroup$
    – aurelije
    Feb 26, 2021 at 10:00
12
$\begingroup$

I can't address the specifics of Python, Pyomo, Gurobi or GAMS, but I can address the general question of using a modeling language (such as GAMS) versus building the model directly in a general programming language (such as Python) via a solver API.

Models written in a modeling language (say GAMS) tend to be easier to read and easier to relate to a problem description than are models coded in a programming language (say Python). That implies a few potential advantages:

  • it is easier to explain the GAMS model to a non-coder than it is to explain the Python model;
  • the GAMS model may be less prone to errors (specifying the wrong variable, reversing the direction of an inequality, indexing errors) than the Python model would be, in part because such errors are more obvious to the human eye;
  • similarly, it may be easier to find errors in the GAMS model (should they creep in) than in the Python model; and
  • the GAMS model may be easier to maintain, particularly if it is handed off to someone other than the person that wrote it.

To me, the main advantages of going straight to a programming language are:

  • you only have to be proficient in one language, rather than two;
  • your code can be used (by other people) without needing a library from the programming language (and associated license);
  • if you are customizing an algorithm for the model (doing something beyond what the solver and GAMS directly support), you are likely going to need "low level" access to model components, which you may not be able to get from the GAMS model.

Your second paragraph ("fast feedback" etc.) does not sound at all correct to me. I use Java rather than Python and CPLEX rather than Gurobi, but I have no difficulty finding out whether a model instance is infeasible (and, if so, which constraints are involved in the infeasibility). Assuming a problem is feasible, whether it can be solved (within time and memory limits) is always an empirical question (try and see).

Improve this answer
$\endgroup$
1
  • $\begingroup$ I had a talk with long-term GAMS user that originally gave me this "fast feedback" point. He explained that in GAMS you can import solution and do a post analysis: why did model calculated this variable so high or so low, and so on. That user was strongly against using Gurobi over python api because from his experience business people will always ask for explanation of result and that we won't be able to provide it easily. Anyhow we are going further with gurobi, GAMS is too awkward and we want automatic application not human operator for business $\endgroup$
    – aurelije
    Jun 19, 2020 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.