I confirm being able to get the optimal MIP solution using the workaround you provided.
For this very same problem (.lp file as attached in my immediately previous message), I was trying to project the solution space into the space of pure binary variables only (_e*) variables in the .lp file.
I followed the steps as specified in https://polymake.org/doku.php/user_guid ... timization
Specifically, I ran the following code via a script:
Code: Select all
use application "polytope";
use vars qw($f $p $q $s);
$f=lp2poly('problemIP_polymake.lp');#lp file from cplex. Should be OK
$p = new Polytope<Rational>($f);
$q = projection($p, [1,2,3,4,5,6,7,8,9,10]);#projects p into space of 1st through 10th variables.
$s = new Polytope(POINTS=>$q->LATTICE_POINTS);
print_constraints($s);
On running this script, my computer essentially hangs and I have to restart my machine after 30 minutes or so.
However, I cannot think of a mathematical reason for why the computation should be so expensive. If I understand the projection algorithm correctly, it should essentially enumerate 2^10 = 1024 points, (since there are 10 binary integer _e* variables in the .lp MIP file), discard the infeasible points and construct the polytope over these 10 dimensions.
Now, the very first constraint of the .lp file is:
Code: Select all
C1_0: _e0_1#0 + _e0_2#1 + _e0_3#2 + _e0_4#3 + _e1_2#4 + _e1_3#5
+ _e1_4#6 + _e2_3#7 + _e2_4#8 + _e3_4#9 = 4
Would it be possible to know at which step polymake encounters the hotspot in the above computation? It appears to me that getting the facets of the feasible integer space should be a reasonably fast operation/computation in this case because the number of feasible integer points should be substantially lesser than 1024.
Thanks again for your continued support.