Hi GAMS world,
I used ‘Target.up = Value’ to set the upper bound of my model target, and the ‘Value’ is the real upper bound (since the upper bound can be easily predicted in my model). However, the SCIP solver returned:
And if I set ‘Target.lo = Value’ or ‘Target.l = Value’, the SCIP solver could solve the model normally and came up with optimal solution. The solution was approximately equal to the solution of an alternative model, and of course the ‘Target’ was less than ‘Value’, though the computation time was much longer than an alternative model.
Why this happened?
Thanks,
Dylan
–
To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.
To post to this group, send email to gamsworld@googlegroups.com.
Visit this group at http://groups.google.com/group/gamsworld.
For more options, visit https://groups.google.com/groups/opt_out.
Hi,
that’s interesting. If you could send me the model to reproduce this issue, that would be great.
In the meanwhile, try setting the GAMS option optcr to 0, i.e., add a line
option optcr = 0;
to your model before the solve statement. Maybe this issue would go away then.
Best,
Stefan
On Thursday, September 12, 2013 4:25:15 AM UTC+2, Dylan Lan wrote:
Hi GAMS world,
I used ‘Target.up = Value’ to set the upper bound of my model target, and the ‘Value’ is the real upper bound (since the upper bound can be easily predicted in my model). However, the SCIP solver returned:
And if I set ‘Target.lo = Value’ or ‘Target.l = Value’, the SCIP solver could solve the model normally and came up with optimal solution. The solution was approximately equal to the solution of an alternative model, and of course the ‘Target’ was less than ‘Value’, though the computation time was much longer than an alternative model.
Why this happened?
Thanks,
Dylan
–
To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.
To post to this group, send email to gamsworld@googlegroups.com.
Visit this group at http://groups.google.com/group/gamsworld.
For more options, visit https://groups.google.com/groups/opt_out.
Hi, Stefan,
When I set ‘option optcr = 0.03;’, the problem went away.
Thanks,
Dylan
在 2013å¹´9月13日星期五UTC+8下åˆ5æ—¶31分05秒,Stefan Vigerske写é“:
Hi,
that’s interesting. If you could send me the model to reproduce this issue, that would be great.
In the meanwhile, try setting the GAMS option optcr to 0, i.e., add a line
option optcr = 0;
to your model before the solve statement. Maybe this issue would go away then.
Best,
Stefan
On Thursday, September 12, 2013 4:25:15 AM UTC+2, Dylan Lan wrote:
Hi GAMS world,
I used ‘Target.up = Value’ to set the upper bound of my model target, and the ‘Value’ is the real upper bound (since the upper bound can be easily predicted in my model). However, the SCIP solver returned:
And if I set ‘Target.lo = Value’ or ‘Target.l = Value’, the SCIP solver could solve the model normally and came up with optimal solution. The solution was approximately equal to the solution of an alternative model, and of course the ‘Target’ was less than ‘Value’, though the computation time was much longer than an alternative model.
Why this happened?
Thanks,
Dylan
–
To unsubscribe from this group and stop receiving emails from it, send an email to gamsworld+unsubscribe@googlegroups.com.
To post to this group, send email to gamsworld@googlegroups.com.
Visit this group at http://groups.google.com/group/gamsworld.
For more options, visit https://groups.google.com/groups/opt_out.