puneetchitkara
commented
4 years ago What could be the source of this error?
Deterministic concurrent LP optimizer: primal simplex, dual simplex, and barrier Showing barrier log only...
Root barrier log...
Elapsed ordering time = 5s Ordering time: 139.02s
Barrier performed 0 iterations in 568.30 seconds Error termination
Explored 0 nodes (0 simplex iterations) in 570.04 seconds Thread count was
1 (of 12 available processors)
Solution count 0
Solve interrupted (error code 10001) Best objective -, best bound -, gap -
Traceback (most recent call last):
File "<stdin>", line 5, in <module> File
"C:\Users\Public\Software\lib\site-
packages\pyomo\solvers\plugins\solvers\GUROBI_RUN.py", line 114, in
gurobi_run
model.optimize()
File "model.pxi", line 833, in gurobipy.Model.optimize
gurobipy.GurobiError: Out of memoryTraceback (most recent call last):
File "C:\Users\Public\Software\Scripts\switch-script.py", line 11, in
josiahjohnston
Reed: Hey Josiah, I just wanted to give you an update on investigating the GLPK issue.
I first ran all of the example models from the examples folder with cbc as the solver and they all worked. Then I tried to run each of them using GLPK as the solver which resulted in the models 3zone_toy, copperplate1, and discrete_build producing errors and copperplate0, custom_extension, and production_cost_models running without error.
Furthermore, the errors that resulted in running the models 3zone_toy, copperplate1, and discrete_build were all actually the same error, which is "missing upper bound". I then looked into the glpk code to see where this error message was being produced and found that it was being produced in the glpcpx.c file. More specifically, it was being produced by the parsing_bounds function, and that the token that was being found after the "<=" / " less than or equal to" token was a symbolic name token, which doesn't trigger any of the if statements and gets thrown in to the else case which is throwing the error that we see.
I haven't been able to figure out more than that, but I will keep working on it. In all honesty I'm not sure whether I should be examining the python code or how pyomo works or how glpk works in order to find out what is going wrong, but I'll check the web to see if anything similar has happened to anyone.
Josiah: That's weird. I think the problem lies in the fuel_markets module because it only appears in the problematic examples. The strange thing is that neither of the two constraints in fuel_markets use a "<="; both are equality constraints.
I'm not sure the best way to proceed either, so checking for similar problems on the web and/or making a simple example that reproduces this error and posting it with a question on the developer's list or stackoverflow makes sense.
Reed: I haven't tried looking into the fuel_markets module, but I'll look into it when I get the chance.
I think the error is fairly simple, but I'm not sure how to fix it. So the actual error I was getting looked something like this
So I went into the file /var/folders/fp/86bgl9md7q90fc9jztz5m4980000gn/T/tmpKOUxAv.pyomo.lp and looked at line 5257 to see what was causing the error, and sure enough the line was just 0 <= x1294 <= inf , but for some reason GLPK only seems to recognize infinity when it is preceded by a + sign or a - sign, which is kind of interesting because in the 5,256 lines before it there were plenty of +inf 's which didn't cause GLPK any problems.
Thanks for the advice regarding what to do next, and I might end up posting something on stack exchange if I can't figure it out.
Josiah: I replicated your process on copperplate1, edited that line from inf to +inf, and got glpsol to solve it, which supports your assessment:
I skimmed through pyomo's interface to GLPK (pyomo/solvers/plugins/solvers/GLPK.py), but had trouble tracing down where the cpxlp file actually gets written out. I finally grep'ed their codebase for cpxlp and found pyomo/repn/plugins/cpxlp.py. Searching that file for 'inf' brought me to line 771-774, which has an if statement that translates no upper bound to " <= +inf\n" and otherwise prints the value of the upper bound. In python, positive infinity is printed as 'inf'. I edited the if statement to be:
and that fixed the problem.
I looked fuel_markets.py and found the source of the problem. The upper bound of fuel that you can purchase in a given supply tier for a particular price will default to infinity if no upper bound was provided - effectively giving an unlimited supply at a given price. This parameter is used as the upper bound for the decision variable FuelConsumptionByTier and is translated into a constraint. Since the upper bound was defined, it used the python depiction of its value, which comes to 'inf'. I added some logic to the lines that specify the upper bound to replace float('inf') with None, and it works now. I just pushed the fix to github.