Hello All,
(this is my first OpenMOD post, so I hope I’m formatting and tagging this correctly)
I’m writing requesting your insights on the feasibility of migrating TIMES 2 JuMP.
Along With @olexandr and @sidk we have been tasked within the IEA-ETSAP community to assess the feasibility of migrating the TIMES Code from GAMS to Julia JuMP.
We have done some prototyping, some benchmarks, had some discussions with JuMP expert developers and had some discussions within the ETSAP Community and I’d love to hear from the OpenMOD community about experiences in migrating an ESOM code from GAMS to Julia-JuMP?
What performance issues did you experience?
1.a Problem creation time?
1.b Solve time?
1.c Data Handling structural change requirements?
What Julia JuMP version were you using?
Did you stay with Julia JuMP? (I believe the GenX folks moved to JuMP and then back to Python?)
If you didn’t stay with Julia JuMP why not?
Do you have strong opinions about other open source ESOM language contenders? LinoPy? Pyomo?
Thank you for your time, If you have insights and want to setup a bilateral google meet, I’m available for that too.
We have done some work porting our OSeMOSYS-derivative GENeSYS-MOD to JuMP in ~2022 when I was visiting SINTEF Energy Research in Norway who were really interested in co-developing an open version of it (previously it only existed in GAMS).
Performance issue definitely lies with problem creation time and/or data handling. Solve time is no issue, as this is really mostly solver-dependent. What we realized is that we had created quite a few data operations that would essentially loop over many sets which GAMS does in a split second, but takes significantly longer in Julia. Therefore, we have started to move more and more processing to the dataset itself to have that performed once and then the model can more or less just read everything in. But also building constraints still takes some time longer than in GAMS, we are still exploring options there.
We started with JuMP version 1.1.0 when we began the conversion efforts.
Yes, we co-maintain our GAMS and Julia versions and have bi-weekly meetings with all developers to ensure that things are aligned.
Since we started the efforts in 2022, some time has passed. Back then, we also considered Linopy and Pyomo. Unfortunately, back then, Linopy was still pretty early in development and did not provide all the features we needed to efficiently code our model. We did some testing with a trimmed-down set of constraints, but the actual data set and compared JuMP and Pyomo and there, JuMP clearly came out on top, which is why we went that way. Also, there were lots of efforts already going with Julia at our departments and SINTEF Energy so it fit in quite nicely.
But a disclaimer: I was/am not the main developer in Julia, that would be @DPinel, so maybe he can weigh in as well.
JuMP developer here. Just wanted to clear up a couple of things since someone linked me to this discussion
What we realized is that we had created quite a few data operations that would essentially loop over many sets which GAMS does in a split second, but takes significantly longer in Julia
Agreed. This is a very common issue for people transliterating between GAMS and JuMP.
Note that this is not JuMP-specific. It will also happen if you use linopy/Pyomo/PyOptInterface etc. The modeling languages that are embedded in a programming language parse the constraints in a way that is fundamentally different to standalone modeling languages like GAMS.
Since it comes up far too often, I’ll link to the (infamous) IJKLM blog post by GAMS and our rebuttal. The takeaway is that choice of data structure matters. (If you look at some of the plots, they claim that JuMP is 2x slower than Pyomo. All that proves is that GAMS used different data structures for their Julia code and Python code. That’s what makes the difference, not anything inherent to either modeling language.) The flexibility that you get in Julia/Python is both a blessing and a curse. You can write fast code in Julia and Python. But you can also write slow code. You need to put on more of a “software engineering” hat when writing JuMP/Linopy/Pyomo models than you do when writing GAMS models.
This early paper describing JuMP offers comparisons with AMPL, GAMS, and Pyomo
If people reference the 2017 paper it needs a bit of context. In the 2018-2022 period we rewrote the entirety of JuMP. We haven’t published any similar performance comparison for the new version of JuMP. I’d say the results are indicative of what can be achieved, but I wouldn’t rely on the exact numbers as fact.
I believe the GenX folks moved to JuMP and then back to Python?
GenX has never been implemented in Python. It has always and continues to use JuMP.
I did port a energy system model from GAMS to JuMP 2 years ago, but I’m not sure it will help. I was learning the GAMS syntax as I was translating it to JuMP, with which I was already familiar. So it’s more a documented example of GAMS→JuMP for beginners than an expert comparison.
As discussed here, most of the work was on adapting data input instructions. Also, I used Symbols a lot.
The motivation was the ability to run this open source model on my computer while I don’t have GAMS.
One other energy system framework written in Julia is AnyMOD.jl from TU Berlin. This was not a translation from GAMS though, but there might be some structural clues on the use of JuMP in their code?
I’ve been experimenting with Claude code in the evenings over the past 10 days as a hobby project to see if Claude Code can implement (some) of the TIMES2JuMP report recommendations and translations.
Apparently Claude can. Initial harness tests are passing full matrix coefficient comparisons from small demo12 TIMES models in GAMS and JuMP solved in CPLEX and HiGHS.
I’ve just made my experiemnts repo public on github. It’s under a GPL3 licence with the option to go to AGPL3 if TIMES_Model upstream is ever released as AGPL3 in the future.
The repo is pre MVP and still very much in development, but I think it’s best practice to build this in public, showing the workings, including public PRs, at least that’s what I’ve overheard proper programmers say.
I’ve done my best to find and link to public open source licenced TIMES models as test models, and I aimed to be prescriptive and explicit about only using openly licenced TIMES models. There are other TIMES models in the public domain, that could be useful, but their legal status and licensing is ambiguous to me so I don’t know if I can use them or not…
(we could do better here within the IEA-ETSAP community as a priority)
You may be interested to look at the repo over the next month.
I intend to continue “building with Claude in public”. Since I am not a programmer, I welcome flagged issues and discussion on how to improve it.
Phase 1 is direct GAMS2JuMP translation. (ongoing MPV dev) - I know it will be 5x-10x slower in JuMP due to some well documented issues with this approach, but first I want to prove the math.
Phase 2 is performance JuMP implementation that was discusssed at length in the TIMES2JuMP report recommendations. (next)
Looking forward to talking with some of you in Bonn & Paris in December.
Interesting work. There are two legal points — which clearly overlap (with “v” added in the quote thee times):
It’s under a GPLv3 licence with the option to go to AGPLv3 if TIMES_Model upstream is ever released as AGPLv3 in the future.
Assuming inbound compatibility, switching to a more restrictive license is straightforward. It does require a project fork. But it does not require the consent of existing copyright holders.
Now the more difficult question: does AI‑generated code attract copyright. At the moment, very likely not:
Hence the license notices provided are irrelevant and users can choose to ignore them.
However, the increasing use of detailed software plans to prompt LLMs, now often typeset, spanning multiple pages, and sometimes subject to wide consultation, might well change the current view that vibe coding does not attract copyright.
In this TIMES framework case, however, the software specification is derived from another product — suggesting that little to no real human creativity was involved anywhere in the coding pipeline.
I want to end with a question that I’ve been thinking about: if frameworks and databanks can be so easily reimplemented with Claude and co, what role should and will project communities play in the future? Will they become more important or less important as LLM‑supported coding becomes the norm?
Thanks for the direction on licencing Robbie. I’m aware of this and am trying to lean carefully towards open licences just in case.
regards your question. I agree, it is one worth reflecting on as a community. I’ve never particularly thought of myself as a model builder, but moreso as an insights farmer.
finding insights through the use of models is how I see my role professionally. I think that tenet will still hold in 6-12 months time.
I was/am stunned how relatively easily it is to do the like for like translation from GAMS to JuMP. Let’s see how if re-writing to performant code is as easy. This is perhaps were this process falls down (for now), and still needs expert JuMP developers and TIMES modellers. (i don’t know at the moment)
The main “creative” part i play in this is not the coding (i’m not a coder), but thinking through the test harness and validation steps and quality control, and articulating that clearly and robustly, defining pages of rules to be followed, and re-directing claude when it gets stuck going a wrong direction in logic.
I think the 50 years of documentation in the TIMES code (books) really helps minimise this though.
The argument is that programming is inexpensive, but code review and acceptance testing are costly. Therefore it makes sense for maintainers to stop accepting pull requests from contributors — and instead just take their ideas, feature requests, and bug reports. The maintainers can then vibe code on their own terms.
