Feasibility of Migrating TIMES to Julia-JuMP from GAMS

Modelling
, , , , , ,
1

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?

  1. What performance issues did you experience?
    1.a Problem creation time?
    1.b Solve time?
    1.c Data Handling structural change requirements?
  2. What Julia JuMP version were you using?
  3. Did you stay with Julia JuMP? (I believe the GenX folks moved to JuMP and then back to Python?)
  4. If you didn’t stay with Julia JuMP why not?
  5. 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.

Le Meas,
James

1 Like
2

Hi!

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).

  1. 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.
  2. We started with JuMP version 1.1.0 when we began the conversion efforts.
  3. Yes, we co-maintain our GAMS and Julia versions and have bi-weekly meetings with all developers to ensure that things are aligned.
  5. 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. :slight_smile:

1 Like
3

This early paper describing JuMP offers comparisons with AMPL, GAMS, and Pyomo. See Fig 2 (page 299) showing coding syntaxes for the same problem:

1 Like
4

Thank you Konstantin, that is very useful to learn from your experience.