Migrating away from GAMS

[glatterf42]

What is this about?

Since GAMS is proprietary software, receiving one of the expensive licenses is often a bottleneck for using message_ix, especially for researchers from the Global South. It would thus greatly benefit our inclusivity and bolster our open source spirit if we moved away from GAMS.

There are several replacement options: pyomo and linopy come to mind most readily. I saw a presentation about linopy and a performance comparison during the OpenMod workshop hosted at IIASA last year, which is why I chose linopy (using the HiGHS solver underneath) to implement a proof of concept for the ixmp4 transport tutorial. A similar migration could be done for the actual MESSAGE GAMS code, though this comprises a lot of code and would thus likely require a significant time investment.

During today's weekly meeting, I brought up my wish to eventually perform this migration. Several colleagues shared their experiences and made suggestions right away:

• @behnam-zakeri shared that we could look into gamspy, too. This, together with GAMS' move to make licenses free for academic institutions would present an alternative to using linopy/HiGHS. We would still have a python interface to the GAMS code, while possibly avoiding the actual rewriting of our GAMS code and likely avoiding the workflow problem presented by @SiddharthJoshi-Git below. The downside would be that our results would still not be completely publicly reproducible and we would still support the closed-source GAMS.
• @SiddharthJoshi-Git shared part of his usual workflow: for quick assessment of results or copying of data, he often uses the .gdx files, which seem to be much more performant than dumping the results to Excel or .csv. Our migration should take this into account and provide ways to quickly and conveniently access the same information stored in the .gdx as well as the .log and .lst files.
• @yiyi1991 expressed her support for this migration and stated that the OseMOSYS team has already done something similar. This might be a place to look for examples as well as an opportunity for collaboration.
• @khaeru noted that we would need to ensure before migration that all GAMS features we use are also available with our choice of tools and that performance is at least at comparable levels.

All of this means that we're not likely to start this migration anytime soon, much less finish it, but I wanted to record this discussion. For future reference and for you, dear enthusiastic community member: please reach out to us to get information on the current status of this project! Any help will be greatly appreciated ❤️

[awais307]

I would like to add one experience where we used GAMS Base Module (academic license) at UVic and then use open-source solvers such as CBC. I briefly checked the results and the results are looking similar on a country scale model with 13 nodes.

[glatterf42]

I would like to add one experience where we used GAMS Base Module (academic license) at UVic and then use open-source solvers such as CBC. I briefly checked the results and the results are looking similar on a country scale model with 13 nodes.

Thanks @awais307! A clarifying question from my side, if I may: Do you use GAMS and CBC simultaneously, i.e. for the same Scenario.solve() workflow? Or do you use either GAMS or CBC for each individual Scenario.solve() workflow and you compared both versions for one model now?
If the former, what do you consider the "GAMS Base Module" and which functions does it fulfill (contrasting to CBC)? Also, could you point to a version of the code that does this somewhere on GitHub?