Skip to content

Collaboration with HiGHS #122

Description

@orlitzky

Hello, I package (and use) lots of scientific and mathematical software on linux. Recently I began packaging HiGHS, as it is now the default MILP solver in SageMath. HiGHS maintains its own fork of METIS with some important changes, a few of which look like they would be useful upstream. Of particular note is thread-safety, copy/pasted for convenience:

  • The original random number generator is not thread-safe
    because it relies on a static state variable. The random
    number generator rand has been replaced with rand_r,
    which stores the state in a local variable. Since rand_r
    is not defined in all C implementations, a local version
    my_rand_r has been added, similar to the GNU reference
    implementation of rand_r. The randon number generator state
    is stored in the ctrl struct and passed as an argument to
    the GKlib functions that need it.

  • Any static __thread variable has been removed, to avoid
    potential issues with thread safety. This required to
    remove gkmcore in GKlib/memory.c and to remove the signal
    handling in GKlib/error.c.

We of course already have the official METIS packaged, as it is used by lots of other important software. As a result it would be greatly beneficial (in terms of developer time, RAM/disk usage, update frequency, etc.) if we could use the official METIS with HiGHS.

Is it feasible for METIS to adopt changes such as the thread-safety mentioned above, assuming there are no negative side effects and that people are willing to create PRs? I don't have any particular insight into the features that HiGHS may desire in the future, but I am CC'ing @filikat in case there are notables ones.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions