Trying to run ARM based GLPK solver using JuMP on a RaspbaerryPi

Specific Domains Optimization (Mathematical)
,
1

Hi everyone, first time posting, I have a problem I need help with, hope someone can help me.

What I’m trying to do is to run an optimization problem using a RaspberryPi 4. To accomplish this I’m using JuMP and GLPK solver. Everything is running fine on my PC, but the problem is that the default GLPK solver included in the package imported through Julia is not compatible with ARM processors. Here is where it gets tricky, at least for me. I can download and install a version of GLPK compatible with ARM processors and works just fine on its own or through python (already tested it on the Raspberry) but when trying to do a custom installation of GLPK following these instructions, nothing happens. I think there is a way to point the GLPK installation to the one that is working with the Raspbaerry ARM processor but I can’t quite make it work, so if anyone could help me I would be forever grateful.

On a different topic I also tried using CBC solver, which works with ARM processors but I have inconsistencies solving problems. Its says ome problems are not feasible when iI know for fact that they are.

PS: These are the steps I followed to install everything GLPK related:

Install:

  • sudo apt-get install glpk-utils libglpk-dev glpk-doc

Custom installation:

  • import Pkg
  • Pkg.add(“GLPK”)
  • Use “dpkg -L libglpk-dev” to locate lib path.
  • ENV[“JULIA_GLPK_LIBRARY_PATH”] = “/opt/lib” (replace with GLPK lib path)
  • Pkg.build(“GLPK”)

Thank you!

2

You need to ensure that JULIA_GLPK_LIBRARY_PATH is set permanently.

3

Exactly what error are you getting? I tried on an RPi 4 and got two different errors. The first was an error that the library could not be found with a long path with lots of ../ in it. This turned out to be because my ~/.julia is a symlink and this badly confused the BinaryProvider machinery that generates deps.jl. After fixing this, I get

ERROR: cfunction: closures are not supported on this platform

It seems like GLPK requires features that are not yet implemented on AArch64.

1 Like
4

When using CBC to solve large MIPs, I’ve found that I need to turn off presolve and/or preprocess to avoid feasibility issues. These are the parameters that need to be set:

"presolve" => "off", "preprocess" => "off"

5

Thank you! Any idea on how to do that exactly? I’ve tried already to create a startup file on ~/.julia/config/startup.jl containing only this:
ENV["JULIA_GLPK_LIBRARY_PATH"] = "/usr/lib/arm-linux-gnueabihf"
But it seemded to do nothing, everything it’s still the same.

Alson when I run dpkg -L libglpk-dev this is what I get:

/.
/usr
/usr/include
/usr/include/glpk.h
/usr/lib
/usr/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf/libglpk.a
/usr/share
/usr/share/doc
/usr/share/doc/libglpk-dev
/usr/share/doc/libglpk-dev/NEWS.Debian.gz
/usr/share/doc/libglpk-dev/changelog.Debian.gz
/usr/share/doc/libglpk-dev/changelog.gz
/usr/share/doc/libglpk-dev/copyright
/usr/lib/arm-linux-gnueabihf/libglpk.so

I’m asuming I’ve got the /usr/lib/arm-linux-gnueabihf library path correctly.

6

This is what I get:

LLVM ERROR: Cannot select: 0x2dbeec8: ch = init_trampoline 0x1379638, 0x25147d8, 0x15aa1a8, 0x2514238, SrcValue:ch<0x2b6e1e8>, SrcValue:ch<0x2a7302c>
  0x25147d8: i32,ch = CopyFromReg 0x1379638, Register:i32 %0
    0x15aee80: i32 = Register %0
  0x15aa1a8: i32 = ARMISD::Wrapper TargetGlobalAddress:i32<i32 (%jl_value_t addrspace(10)**, i32, i32)* @"jlcapi_#15_36057"> 0
    0x19fe480: i32 = TargetGlobalAddress<i32 (%jl_value_t addrspace(10)**, i32, i32)* @"jlcapi_#15_36057"> 0
  0x2514238: i32,ch = CopyFromReg 0x1379638, Register:i32 %1
    0x227b3d0: i32 = Register %1
In function: jlcapi_#15_36057_gfthunkmake

I’m asuming its possible because I can use GLPK through python with no problem so I’m guessing the ARM version of GLPK is working.

7

I’m getting this:

LLVM ERROR: Cannot select: 0x2dbeec8: ch = init_trampoline 0x1379638, 0x25147d8, 0x15aa1a8, 0x2514238, SrcValue:ch<0x2b6e1e8>, SrcValue:ch<0x2a7302c>
  0x25147d8: i32,ch = CopyFromReg 0x1379638, Register:i32 %0
    0x15aee80: i32 = Register %0
  0x15aa1a8: i32 = ARMISD::Wrapper TargetGlobalAddress:i32<i32 (%jl_value_t addrspace(10)**, i32, i32)* @"jlcapi_#15_36057"> 0
    0x19fe480: i32 = TargetGlobalAddress<i32 (%jl_value_t addrspace(10)**, i32, i32)* @"jlcapi_#15_36057"> 0
  0x2514238: i32,ch = CopyFromReg 0x1379638, Register:i32 %1
    0x227b3d0: i32 = Register %1
In function: jlcapi_#15_36057_gfthunkmake

I’m assuming it should work only beacuse I can run GLPK through python, so I guess the ARM version of GLPK is working just fine.

8

Thank you! I tried it but I still got the same problem:

ERROR: LoadError: Unable to retrieve solution from 48.
  Termination status: OPTIMAL
  Primal status:      FEASIBLE_POINT
  Dual status:        NO_SOLUTION.
A MathOptFormat file was written to `subproblem.mof.json`.
See https://odow.github.io/SDDP.jl/latest/tutorial/06_warnings/#Numerical-stability-1
for more information.

I know that the subproblem is feasible as is modeled that way and also I solved it in my PC with no problems.

9

Ah what?! You’re using SDDP.jl on a RPi? Why???

The issue is Cbc doesn’t return dual solutions (Dual status :NO_SOLUTION), which we need.

You could try Clp, but that might be a bit slow, and it can have some other numerical issues.

10

Oscar! Sorry I didn’t mentioned it earlier, I just realized you were the one answering me!!
Well, I’m using SDDP on a RPi because I need to solve a stochastic problem on a remote location on a daily basis using idealy a really small device, so RPi came to mind. Originally the idea was to use python, but it doesn’t appear to be anything as good as what you’ve done with SDDP.jl. There is no problem using Julia though, the only problem has been this ARM processor limitation that most solvers have. That’s why I’m trying to get GLPK or Cbc to work, having both supposedly ARM compatiblity, but I’m totally stuck!

11

Do you have it working, debugged, and fast on your main machine? I would only go to the Pi once you’re reasonably confident it is going to work. Perhaps open an issue in SDDP.jl, or send me an email. Even if you get a solver working, I think you’re going to have serious performance issues, particularly associated with the amount of RAM available.

12

I do have it working on my PC and it’s fast. I’m not solving a particularly large problem, that’s why I think I can get this to work. How do I get your email? I’ll be so grateful if somehow you are able to help me and I can get this to work.