Hello,

while using the crate, we can send options to the solver via model.set_options('option_string',value), we can control some of the options from here however when we need to write the solution file and/or the model file, nothing happens.

Other than that we do think that the crate is very easy to use, and appreciate all the work that has been put into it :).

Best regards

Alaa

FYI: The link to https://www.maths.ed.ac.uk/hall/HiGHS/HighsOptions.html/ in

does not work.

Hello, I'm opening this issue to discuss the option to upstream some changes we implemented to add support for HiGHS in wasm32-unkown-unknown targets.

This is a somewhat non-trivial business, but was necessary in our use case to get access to a fast LP solver from the browser. Since we have figured out how to do it, we thought we may spare someone else the trouble.

The current strategy we are using works as follows. I have a forked version of your crate (here), which intercepts the calls to highs-sys and instead runs them through wasm-bindgen to some external symbols, which are placed in the global JS scope.

We then take the highs library and compile it to C++ with emscripten. Unfortunately, this means it is ABI-incompatible with wasm32-unknown-unknown, so we cannot directly link against our main rust binaries. But we have written some light glue code that allows us to pretend we have a JS implementation of the highs-sys functionality. Thanks to the architecture of your crate, the shim is not too extensive.

The full nix derivation for buildings highs with emscripten and adding our bindings can be found here.

Overall, this works reliably in practice. There is a subtle memory corruption bug, for which we would appreciate help with debugging, but we have been successful in avoiding it by slightly padding the LP problems. Aside from this, it is pretty much done and good to be merged.

Hi there,

Thanks for creating this useful library.

I have been running into some issues when using the LP solver. The specific problem is the following: I run the highs LP solver in a function, and sometimes (but not always, depending on the exact function call) after successfully solving an LP and exiting the function, one of "Segmentation fault", "Fatal error: glibc detected an invalid stdio handle", or "double free or corruption (!prev)" get's thrown and my program crashes.

I believe the LP was successful because the 1) error seems to get thrown after exiting the function where I call highs, and 2) I can access the solution and the results seem reasonable. Furthermore, the Highs.log file is empty.

I'm also calling highs directly from this crate and not from good-lp.

Let me know if you have any ideas about what the issue is. I've attached the output of dbg!(pb), dbg!(solved.get_solution()) in a log file below.
log.txt

Thank you!

Is it possible to use just the LP solver part of HiGHS using this crate? I am looking to implement my own branch and bound algorithm around it and just need it for evaluating relaxations. Is this level of control obtainable with this crate? Additionally, am I able to read .mps files with this crate?

Thanks!

Highs doesn't build using Github CI on macos-latest (see complete log).

The error is ld: library not found for -lomp, which seems related to this stackoverflow thread, where the proposed solution is to provide the full path for libomp.dynlib.

I have no idea how to make this work transparently when installing the crate, but it would be nice to have.

Hi, i've been writing for some time a program using good lp, i've a model with 2k rows of constraints and while i've implemented it in good lp using the highs solver specified in the features it gets detected as unfeasible. On the other hand if i debug the same model printing it as an lp file and pass it within lpsolve ide it gets solved specifying that some of the constraints are redundant. I wonder if this can be a feature to be added or should be classified as a presolve bug in the highs crate/module since, as me, i believe many models can be represented using "implicitely" redundant constraints. As implicit i mean bounds that in some solution result as redundant and changing a parameter in the problem (another bound), are no more redundant.

It looks like the performance problem with passing a problem row by row was fixed. We should call the addRow function directly instead of caching the matrix in rust before passing it to c++

See
ERGO-Code/HiGHS#480 (comment)

Thanks for maintaining these LP libraries.

I've noticed the following when using good_lp with Highs, hence reporting it here.

Input

Example program:

use highs::{RowProblem, Sense};

fn main() {
    let mut problem = RowProblem::new();
    // Minimize x + y subject to x ≥ 0, y ≥ 0.
    let x = problem.add_column(1., 0..);
    let y = problem.add_column(1., 0..);
    let c = 0.; // Try changing this to something nonzero.
    problem.add_row(..1, &[(x, 1.), (y, c)]); // 1 ≥ x + c y.
    let solution = problem.optimise(Sense::Minimise).solve().get_solution();
    println!("{:?}", solution.columns());
}

Actual output

When run with highs 1.2.1, it panics at the optimise call:

thread 'main' panicked at 'invalid problem: Warning', …/highs-1.2.1/src/lib.rs:200:34

Expected output

It should just print the unique solution to the problem (x = y = 0) without panicking.

highs 0.6.1 works as expected.

Workaround

The issue disappears if the coefficient c is nonzero. Thus, one can skip terms c y when generating constraints by checking if the coefficient c is zero.

In the above example, calling problem.add_row(..1, &[(x, 1.)]) instead of problem.add_row(..1, &[(x, 1.), (y, c)]) works.

When I try to run Highs in parallel using rayon, I get terminated by signal SIGSEGV (Address boundary error), but only on macOS. This issue is hard to reproduce, only happening when the problem is large. Adding a Mutex around code that calls into Highs did not help. Any ideas on how to further debug this issue given that valgrind is Linux only?