Performance improvement when saving the solution Topic is solved

[Janisch]

Hello all,

I have a problem with the runtime of my model. Namely, I found out that the step:
Pareto_X_TR(solu,p,s,m,i,j)$((solu.val = iter) AND f_c_r(s,m,i,j) AND p_s(p,s)) = x_TR.L(p,s,m,i,j);
takes a very long time. In this step I save the solution.

Code: Select all

iter   = 0;
Set
solu         'Number of possible solutions' / 1*%100000% /;
Parameter
Pareto_X_TR(solu,p,s,m,i,j)     Results for variable x_TR

repeat
  solve mod_epsmethod maximizing a_objval using minlp;
  iter=iter+1;
  Pareto_X_TR(solu,p,s,m,i,j)$((solu.val = iter) AND f_c_r(s,m,i,j) AND p_s(p,s)) = x_TR.L(p,s,m,i,j);
until (elapsed_time>time_limit);

The model should be solved thousands of times. The smaller the set solu is, the faster it goes.
Now my question: Is there a better approach for this that improves the performance significantly?

Many greetings
Janisch

[abhosekar]

You can loop over the set solu to get rid of one of the $ conditions stating solu.val =iter
You can simply loop(solu, ....)

How do you know that the time is taken by that statement and not by the solve statement? Would be great if you can share profile results.

- Atharv

[Janisch]

Here my profile evaluation:

If a solution was found in the "iter" run, this number is to be stored and then serve as index for the storage of the variable Pareto_X_TR(solu,p,s,m,i,j).

Is there a way to simply add the new solution to the array?

[dirkse]

Janisch,

You are trying to use GAMS like you would use a programming language like C or Java, e.g. you have an iteration index and a repeat loop, you store solutions based on the value of the numerical value of the iteration index, and you used the phrase "add the new solution to the array" in your post on this topic. It is possible to do all this with GAMS, but that isn't really the GAMS way to do it.

GAMS data is indexed, so you access it via sets and set indices, not integer values as you would an array. I am including a little example that shows how I would do this "the GAMS way". Note the use of the larger set soluUni of all possible solutions, the subset of actual solutions found, and the singleton set indicating the current "iterate" value. Also note that in this example assigning to a singleton changes the value of the "iterate", but assigning to the subset of solutions found grows this subset:

https://www.gams.com/33/docs/UG_SetDefi ... _singleton

In the end, we have a record of the solutions we have processed saved and the results associated with each solution.

gamsIdiom.gms

(575 Bytes) Downloaded 197 times

The timing issues may be helped by this change, but this post is long enough already.

-Steve

[dirkse]

Janisch,

You mention that you suspect the statement

Code: Select all

Pareto_X_TR(solu,p,s,m,i,j)$((solu.val = iter) AND f_c_r(s,m,i,j) AND p_s(p,s)) = x_TR.L(p,s,m,i,j);

is a bottleneck and you'd like to speed it up.

Previously I explained how to use a singleton set to make this

Code: Select all

Pareto_X_TR(singleSolu,p,s,m,i,j)$(f_c_r(s,m,i,j) AND p_s(p,s)) = x_TR.L(p,s,m,i,j);

If that doesn't help, I would first change the order of the two expressions in the AND: it is sometimes better to check sets occurring more on the left and work your way right, although GAMS has lots of built-in performance optimization so sometimes these things are done internally. So this:

Code: Select all

Pareto_X_TR(singleSolu,p,s,m,i,j)$[p_s(p,s) AND f_c_r(s,m,i,j)] = x_TR.L(p,s,m,i,j);

Finally, you could pre-compute exactly the result of the dollar-on-the-left condition

Code: Select all

[p_s(p,s) AND f_c_r(s,m,i,j)]

once, before the loop (assuming it does not change inside the loop) and then use that. This is as fast as it gets:

Code: Select all

set psmij(p,s,m,i,j);
psmij(p,s,m,i,j) = p_s(p,s) AND f_c_r(s,m,i,j);

* and now in the loop do this
Pareto_X_TR(singleSolu,psmij(p,s,m,i,j)) = x_TR.L(p,s,m,i,j);

-Steve

[Janisch]

Hello Steve,

first of all many thanks for your detailed explanations! Yes partly I am still very much in the Java or C syntax on the way

Your example was great! I was able to implement it directly in my model. The performance is much better now.

Thanks also for the other tips. I will also test them in the next days, if it has an influence on the performance.

Many greetings and have a nice weekend
Janisch