GUSS or Control API for SDDP implementation

GAMS
,
1

Hello!

I am looking to write my own implementation of the SDDP algorithm in GAMS, with data coming from MATLAB. From what I have gathered reading the forum and the documentation, it appears that I have a few options:

  • Modify the sddp.gms example that uses GUSS, importing all the data from a gdx file (created with Matlab Transfer API). This is interesting and straightforward, but seems limiting if I want to add custom cuts or other routines to the algorithm, for instance.
  • Use GUSS for the inner loops of the SDDP only, and orchestrate the main loop using the Matlab Control API.
  • Write the whole algorithm using the Matlab Control API, using a ModelInstance for each subproblem.

My question is: are there any performance penalties/benefits in using either one of the three approaches? In other words, how performant is GUSS compared to creating Model Instances via API?
Any insights is valuable!

Thank you
Paolo

2

Paolo,

GUSS and Control API’s GamsModelInstance are based on the same technology. GUSS needs all the data for the subsequent scenario run at start, while GamsModelInstance can be modified “on the fly”. The main of the work happens when you instantiate the GamsModelInstance. The work for the update is proportional to the “size” of the update. Different solvers work differently with GamsModelInstance. Some can keep the model “hot” in the solver and actually update the instance inside the solvers, others need to set the solver up fresh with each solve.

GUSS has been implemented for speed, so the scenario data layout allows to zoom through, so if you just reimplement GUSS for parts of your algorithm, it might be better to use GUSS directly. The GamsModelInstance does give you more flexibility though.

The GAMS MATLAB Control API is based on the GAMS Java Control API and MATLAB’s ability to use Java. I don’t know how much overhead there is in MATLAB when using Java, but this is not specific to the GAMS MATLAB Control API.

Please also note, that the model rim of a GamsModelInstance needs to stay constant. This is very unfortunate when you want to add cuts to a GamsModelInstance. One way to do that is to have a couple (e.g. 500 or so) placeholder equations with a dense non-zero structure (everywhere a cut can have a coefficient) that are inactive (e.g. large rhs or EPS, i.e. 0, as coefficients) and then the updater fills this with real cut information. Assuming you add a single cut in each iteration, you can do that for some iterations before you need to instantiate the GamsModelInstance again, with the already generated cuts and again 500 placeholders for the cuts from the next iterations…

Hope this helps,
-Michael

3

Thank you Michael for the clear and thorough answer!

I have just another question on the topic. Does ModelInstance convert scenario parameters into variables, possibly creating non-linear expressions? Looking at the documentation, I understand this is what GUSS does, and since you mentioned GUSS and ModelInstance use the same technology, I expect this is the case for ModelInstance as well, but I would love to be wrong on this :laughing:

Thank you again
Paolo