6

I have a Docker machine running Linux. I am using Pyomo with the GLPK solver. I installed GLPK from the shell command line for the Docker image, using apt-get install glpk-utils

I have all my code saved under the subfolder /code

I can see glpsol is installed under path: /usr/bin

I can see that /usr/bin is a path under the PATH environment variable.

I have the relevant imports as follows:

from pyomo.environ import *
from pyomo.opt import SolverFactory

When I run opt = SolverFactory("glpk"), I get the following error:

Attempting to use an unavailable solver.

The SolverFactory was unable to create the solver "glpk"
and returned an UnknownSolver object.  This error is raised at the point
where the UnknownSolver object was used as if it were valid (by calling
method "solve").

The original solver was created with the following parameters:
    type: glpk
    _args: ()
    options: {}

I am not sure if this is Docker-related or if I should have used a different package for apt-get.

I have used all the most recent versions of everything.

Would really appreciate any help with this.

Ryan Skene
  • 864
  • 1
  • 12
  • 29
  • What line did you use to edit your PATH? I recently had a similar issue in that I had set up the PATH in my docker images by adding an export to .bashrc using "~" (i.e., the user shortcut symbol). This was fine as long as the docker image was started with /bin/bash. However, the gitlab-runner I had configured was launching my test environment using /bin/sh, which did not seem to correctly interpret "~". Any chance you've done the same? – Gabe Hackebeil Mar 11 '18 at 20:49
  • Sorry, I didn't read very carefully. If `glpsol` is already in `/usr/bin`, then Pyomo should be finding it. – Gabe Hackebeil Mar 11 '18 at 20:53
  • i have python saved in `/usr/local/bin` on the docker image. on my local machine, i have both python and glpsol in `/usr/local/bin` and it works fine. perhaps the error results from the executable not being in the exact same folder? – Ryan Skene Mar 12 '18 at 02:05
  • i tried the above change but that did not fix the issue – Ryan Skene Mar 12 '18 at 02:29
  • If you push your docker image to DockerHub, I’ll start it locally and see if I can figure out what is wrong. – Gabe Hackebeil Mar 12 '18 at 12:01
  • tried manual install to `/usr/local/bin` and that is still failing. ive checked the source code a bit and it is failing at `opt=PluginFactory()`, which is pulled from pyutilib. Haven't been able to dig further than that. – Ryan Skene Mar 13 '18 at 00:52
  • I started your docker image using /bin/bash, ran `apt-get update`, `apt-get install glpk-utils`, and `pip install pyomo`. Everything works fine after that. Are you doing something different? – Gabe Hackebeil Mar 14 '18 at 01:47
  • tried that and no improvement. i agree that the glpk test works fine, but did you try to run pyomo from within the app? if you go to the pyondo app, there is a class under `pyondo.py` that contains the code I want to run. then i have a view that runs the class' main method. if i run via that app, i continue to get the error message above. – Ryan Skene Mar 14 '18 at 10:36
  • 2
    it seems like it is related to running the code via a django view. b/c i can run the code in a standalone script in whatever folder and it works fine. if i run the code through the view, whether via a method or just using the direct code, i get the error. – Ryan Skene Mar 14 '18 at 11:04
  • Gabe, this seems related to signals/threading in django, which i know nothing about. so im going to read up and see if i can find a workaround and if not try another question later. thanks for your help! – Ryan Skene Mar 15 '18 at 09:02

0 Answers0