HiGHS package for Octave

[mmuetzel]

I took the liberty to convert the code at https://github.com/jajhall/octave to an Octave package here:
https://github.com/mmuetzel/oct-highs

It can be installed with the following command in Octave:

pkg install https://github.com/mmuetzel/oct-highs/archive/main.zip

If HiGHS isn't installed at the default prefix, it might be necessary to add the path to the .pc file to PKG_CONFIG_PATH before installing the package. That can be done with the following command in Octave:

setenv("PKG_CONFIG_PATH", [getenv("PKG_CONFIG_PATH"), pathsep, "d:/SVN/Octave/HiGHS/pkg/lib64/pkgconfig/"])

When using the package, you'll need to make sure that Octave can find the HiGHS library. How to do that depends on the OS. On Linux, something involving LD_PRELOAD would probably work.

After installing the package, its test suite passes for me (on Windows):

>> pkg test highs
Testing functions in package 'highs':

Integrated test scripts:

  ..kages\highs-1.0.0\x86_64-w64-mingw32-api-v57\__highs__.cc-tst  pass    1/1
  ..s\AppData\Roaming\octave\api-v57\packages\highs-1.0.0\highs.m Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
 pass    9/9

Fixed test scripts:


Summary:

  PASS                               10
  FAIL                                0

See the file D:\SVN\Octave\opkg-highs\fntests.log for additional details.

0 (of 1) .m files have no tests.

Please help improve Octave by contributing tests for these files
(see the list in the file D:\SVN\Octave\opkg-highs\fntests.log).

I'd like to donate this package (instead of maintaining it myself). I wouldn't be able to give any substantial help when it comes to actually using the package.

Please, feel free to fork/copy the package repository.
I added the MIT license to the package. That might not be possible. IIUC, the original work was based on __glpk__.cc in Octave which uses the GPL. I don't know how much of that code was re-written by @jajhall. Dependent on that, the package might need to be distributed under the GPL (or a compatible license) as well...

[jajhall]

Thanks for this. It's still not the elegant integration that I understood to be possible once we can apt get HiGHS and equivalent on Windows, but it's progress. I worked from __glpk__.cc, so I guess that makes it GPL. Not that I feel that it's ready for distribution yet. Maybe later someone on the HiGHS team will rewrite everything from scratch - as we also want to give Octave access to the HiGHS QP solver, and that needs a separate method. Since this isn't really a HiGHS issue, I'll move it to discusisons

[jajhall]

So long as the package comes with a health warning that it doesn't just "plug-and-play" on any system, I'm happy for it to be added to https://github.com/gnu-octave/packages now. It's better that Octave users who can make it work have access now, than them having to wait until it's perfect.

Since you're best qualified to communicate how to install it and (I guess) know how to add a package to https://github.com/gnu-octave/packages, could you do it? I don't have anyone on the HiGHS team who can take on the task at the moment. If the following isn't OK as an icon, please let me know, as I can easily create versions to a specification.

[mmuetzel]

I'd be happy to help with getting the package released and adding it to the package index.
However, I don't feel qualified to maintain the package after that. I could help with questions regarding packaging or Octave itself. But anything actually concerning HiGHS is out of my comfort zone. It would be nice if you (or someone from your team) could step in as the "official" maintainer. I could try to stay around for Octave-specific questions.
It would probably be a good first step to move the repository from my GitHub to ERGO-Code (or somewhere else?). Once that is done, I could create a PR to add it to the package index.

Regarding a "health warning": The description on the package index can contain arbitrary text. It could also include some basic instructions for the prerequisites for installing the package or redirect to somewhere where those steps are explained in a bit more detail. (But it probably won't need to be much more than what I wrote in the original post.)
See, e.g. here, for what a package index entry could look like.

It would also be possible to change the package version from 1.0.0 to 0.1.0 to give a hint that this is a very early version of the package.

Having written that, I started seeing random crashes or other errors when running test highs in Octave.
E.g.:

octave:1> getpid
ans = 7912
octave:2> pkg load highs
octave:3> test highs
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Assertion failed: length[n-1] == nz, file __highs__.cc, line 150
fatal: caught signal Aborted -- stopping myself...

Or:

octave:2> pkg load highs
octave:3> test highs
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
PASSES 9 out of 9 tests
octave:4> test highs
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields 0
Run model yields 0
Running HiGHS
Defined consts and bounds
Defined LP
Pass model yields -1
Assertion failed: return_status == HighsStatus::kOk, file __highs__.cc, line 193
fatal: caught signal Aborted -- stopping myself...

The crashes happen in about 50% of the time.
Maybe some out of bound indexing somewhere? I notice some loops iterating from 1 to <= nz (instead of from 0 to < nz).

These failing asserts are particularly bad because they will shut down Octave immediately and a user might loose unsaved work.

[jajhall]

OK I'll move the the repository from your GitHub to ERGO-Code, install it in Octave according to your instructions, and try to reproduce the crashes and, hence, fix the bugs.

Once I'm happy with it, and you get the package released and added it to the package index, we'll certainly take over. As with many such things, once the "magic" has been done to create something new that's unfamiliar, maintaining it is relatively easy.

[mmuetzel]

Sounds good to me.

During debugging it might be easier to build __highs__.oct manually instead of as part of the package installation process. To do that you could probably use something like the following from inside Octave:

setenv('CXX', 'g++ -g -std=gnu++11');
mkoctfile -I/path/to/highs/headers -L/path/to/highs/libs -lhighs __highs__.cc

Or alternatively from a shell:

CXX="g++ -g -std=gnu++11" mkoctfile -I/path/to/highs/headers -L/path/to/highs/libs -lhighs __highs__.cc

That might be easier than generating a package tarball for each test.

[jajhall]

Thanks for all this: all noted. I've got exam marking that needs doing, so I won't be able to look at this before the weekend