Best possible is a bound, not a solution. The Gurobi folks explain this nicely: https://www.gurobi.com/resource/mip-basics/
Hope this helps,
Michael
Search found 1042 matches
- 3 years ago
- Forum: Syntax
- Topic: index of elements in an unordered subset
- Replies: 2
- Views: 2373
Re: index of elements in an unordered subset
Bahar, This is not possible with a one dimensional set. In GAMS there is only one order, the input label order, so if you have a set i /1*10/, then all sets with these elements will have this natural order. You can work around this by making your subset two-dimensional: set subset(i,i) / 1.4,2.3,3.1...
- 3 years ago
- Forum: Syntax
- Topic: Merge input data of a parameter
- Replies: 2
- Views: 2261
Re: Merge input data of a parameter
I would read the five matrices at compile time into different symbols and do the merge at execution time. For 5 matrices there is little need to automate: set i / ... /, j / ... /; parameter d1(i,j), d2(i,j),d3(i,j),d4(i,j); $gdxin d1 $load d1 $gdxin d2 $load d2 ... set m / 1*5 /; parameter d(m,i,j)...
- 3 years ago
- Forum: Syntax
- Topic: $ifthen with $else code block issue
- Replies: 5
- Views: 3804
Re: $ifthen with $else code block issue
Andrew, All the pieces look okay to me but without the entire source it is hard to say where the problem is. I can recommend to use $ifThen/$else/$endIf with suffix names. This way the compiler reports things in a better way: $ifThen.label1 cond1 ... $ifThen.label2 cond2 ... $endIf.label2 $else.labe...
- 3 years ago
- Forum: Solvers
- Topic: Not convex with MOSEK solver
- Replies: 7
- Views: 6366
Re: Not convex with MOSEK solver
As I said before, MOSEK is strict for what it expects as SOCP constraints. The definition of the various SOCPs can be found e.g. here: https://www.gams.com/latest/docs/UG_LanguageFeatures.html#UG_LanguageFeatures_ConicProgramming_Intro. So you have a rotated quadratic cone for MOSEK you can't have c...
- 3 years ago
- Forum: Solvers
- Topic: Not convex with MOSEK solver
- Replies: 7
- Views: 6366
Re: Not convex with MOSEK solver
Mosek is pretty pure in terms of how your cones need to look like. Cplex and Gurobi try to transform your constraints and see if they can reformulate this into a convex cone. Without seeing the constraints/model it is hard to say, but the message from MOSEK about PSD indicates that MOSEK interpreted...
- 3 years ago
- Forum: Solvers
- Topic: Why is GAMS stucked at an elapsed time during searching for a solution?
- Replies: 9
- Views: 6977
Re: Why is GAMS stucked at an elapsed time during searching for a solution?
I would first try to see if you can reproduce this with the latest version. You could e.g. submit to NEOS and use the latest version there. -Michael
- 3 years ago
- Forum: Solvers
- Topic: Why is GAMS stucked at an elapsed time during searching for a solution?
- Replies: 9
- Views: 6977
Re: Why is GAMS stucked at an elapsed time during searching for a solution?
Yes, this seems odd. It could be that Cplex is stuck solving the node lp. You could turn on the detailed node log by setting option mipdisplay = 5. This will give you much more output (all the LP logs from the nodes) but might give you an idea what's wrong. If you are using the latest version of Cpl...
- 3 years ago
- Forum: Modeling
- Topic: I need help from someone with a paid license
- Replies: 3
- Views: 2901
Re: I need help from someone with a paid license
The latest versions of Studio and GAMS integrate the execution of GAMS jobs on NEOS (see https://www.gams.com/33/docs/T_STUDIO.html#STUDIO_NEOS). You can do the compilation on your local machine with a demo/community license and execute (if the model limits exceed the demo/community license limits, ...
- 3 years ago
- Forum: Solvers
- Topic: Why is GAMS stucked at an elapsed time during searching for a solution?
- Replies: 9
- Views: 6977
Re: Why is GAMS stucked at an elapsed time during searching for a solution?
There are phases in Cplex that can take a very very long time (e.g. processing of node 0) without messages to the log. If you send more of your log, then perhaps we can answer better. -Michael