c++ - gurobi - Error code = 10004 Unable to retrieve attribute 'X'

Question

I am getting an error in my c++/gurobi file:

Error code = 10004 Unable to retrieve attribute 'X'

I read that this might have something to do with labels? But I don't see how there is a problem. It works for some input files, but not for others. So I have created a toy file, t5.txt in attachment. This file does not work, but removing the last column and setting 8 to 7 fixes it. I am puzzled...

Below is the output of model.write. Everything seems to make sense, any Ideas what I am doing wrong? Whenever I do a model.write(test.sol), the program stops, so there seems to be something wrong with the solution>

Attachments: main.cpp -> https://dl.dropboxusercontent.com/u/13564139/main.cpp

input.txt -> https://dl.dropboxusercontent.com/u/13564139/t5.txt

Maximize
  15 student_has_projects4.1
Subject To
 R0: student_has_projects0.0 + student_has_projects1.0
   + student_has_projects2.0 + student_has_projects3.0
   + student_has_projects4.0 + student_has_projects5.0
   + student_has_projects6.0 + student_has_projects7.0 <= 4
 R1: student_has_projects1.0 + student_has_projects2.0 >= 1
 R2: student_has_projects2.0 + 2 student_has_projects5.0 <= 2
 R3: student_has_projects2.0 + 2 student_has_projects5.0 >= 1
 R4: student_has_projects0.0 + student_has_projects3.0
   + student_has_projects4.0 + student_has_projects6.0
   + student_has_projects7.0 >= 1
 R5: student_has_projects2.0 + student_has_projects5.0 <= 1
 R6: student_has_projects0.1 + student_has_projects1.1
   + student_has_projects2.1 + student_has_projects3.1
   + student_has_projects4.1 + student_has_projects5.1
   + student_has_projects6.1 + student_has_projects7.1 <= 4
 R7: student_has_projects1.1 + student_has_projects2.1 >= 1
 R8: student_has_projects2.1 + 2 student_has_projects5.1 <= 2
 R9: student_has_projects2.1 + 2 student_has_projects5.1 >= 1
 R10: student_has_projects0.1 + student_has_projects3.1
   + student_has_projects4.1 + student_has_projects6.1
   + student_has_projects7.1 >= 1
 R11: student_has_projects2.1 + student_has_projects5.1 <= 1
 R12: student_has_projects0.2 + student_has_projects1.2
   + student_has_projects2.2 + student_has_projects3.2
   + student_has_projects4.2 + student_has_projects5.2
   + student_has_projects6.2 + student_has_projects7.2 <= 4
 R13: student_has_projects1.2 + student_has_projects2.2 >= 1
 R14: student_has_projects2.2 + 2 student_has_projects5.2 <= 2
 R15: student_has_projects2.2 + 2 student_has_projects5.2 >= 1
 R16: student_has_projects0.2 + student_has_projects3.2
   + student_has_projects4.2 + student_has_projects6.2
   + student_has_projects7.2 >= 1
 R17: student_has_projects2.2 + student_has_projects5.2 <= 1
 R18: student_has_projects0.0 + student_has_projects0.1
   + student_has_projects0.2 = 1
 R19: student_has_projects1.0 + student_has_projects1.1
   + student_has_projects1.2 = 1
 R20: student_has_projects2.0 + student_has_projects2.1
   + student_has_projects2.2 = 1
 R21: student_has_projects3.0 + student_has_projects3.1
   + student_has_projects3.2 = 1
 R22: student_has_projects4.0 + student_has_projects4.1
   + student_has_projects4.2 = 1
 R23: student_has_projects5.0 + student_has_projects5.1
   + student_has_projects5.2 = 1
 R24: student_has_projects6.0 + student_has_projects6.1
   + student_has_projects6.2 = 1
 R25: student_has_projects7.0 + student_has_projects7.1
   + student_has_projects7.2 = 1
Bounds
Binaries
 student_has_projects0.0 student_has_projects0.1 student_has_projects0.2
 student_has_projects1.0 student_has_projects1.1 student_has_projects1.2
 student_has_projects2.0 student_has_projects2.1 student_has_projects2.2
 student_has_projects3.0 student_has_projects3.1 student_has_projects3.2
 student_has_projects4.0 student_has_projects4.1 student_has_projects4.2
 student_has_projects5.0 student_has_projects5.1 student_has_projects5.2
 student_has_projects6.0 student_has_projects6.1 student_has_projects6.2
 student_has_projects7.0 student_has_projects7.1 student_has_projects7.2
End

Answer 1

The issue is that your lp instance is infeasible so the call to .optimize() results in an infeasible status. From your code

model.write("test2.lp");
model.optimize();
model.write("forum2.sol");

if(model.get(GRB_IntAttr_Status) != GRB_OPTIMAL){
    cout << "niet optimaal " << endl;
}

You are writing a .sol file before you check for success. Gurobi gets the 'X' attributes from the variables when it writes a .sol file. If the optimization fails, the 'X' attributes aren't available and an exception is thrown. You should make sure that gurobi has a solution before you write a .sol file, or get many attributes, including 'X', 'Pi' and 'ObjVal'. The OPTIMAL status codes assures you that that there is an available solution, but codes like SUBOPTIMAL also indicate that there is a solution available and others like TIME_LIMIT, NODE_LIMIT mean there might be a solution available. You can get the attribute SolCount to get a definitive indication that there is a solution available.

Your problem instance is infeasible because constraints (R1, R7, R13 imply you need at least 3 projects for students 1 and 2, but constraints (R19, R20) imply they can have exactly 1 project each. You can see this by using the IIS solver. In interactive gurobi you can get get an Irreducible Inconsistent Subsystem

m = read("test2.lp")
m.optimize()
m.computeIIS()
m.write("test2.ilp")