Replies: 5 comments 4 replies
-
|
I agree that It's probably the best way forward. A few things to mention:
|
Beta Was this translation helpful? Give feedback.
-
|
@filikat With Nick Gould, we interfaced METIS 4, METIS 5.1.0, and METIS 5.2.1 in GALAHAD. All versions are available. cc @nimgould |
Beta Was this translation helpful? Give feedback.
-
|
@amontoison I did play a bit with the options, especially no2hop and pfactor. They do make a big difference sometimes. The problem is that whatever Metis options we set as default in HiGHS, they need to work for generic problems. The default Metis 5.2.1 seems to produce slightly better orderings than the default 5.1.0; for the PyPSA problems it performs enormously better. |
Beta Was this translation helpful? Give feedback.
-
|
Just an observation from GALAHAD land. As Alexis mentioned, we have a Metis module, actually an extraction of the Metis nodend parts as those are all we need, that provides native access to Metis 5.1/5.2, but also optional hooks into the license-restricted Metis 4.0 (with instructions of how to find and link the latter). The reason for this is that we have often observed, both in GALAHAD and HSL, Metis 4.0 finds much better orderings, and is faster in doing so. We also support both 32 and 64 bit integers at the same time, for what it is worth. I should also add that nested dissection (and that is what Metis does) can be very bad for matrices with (permuted) band structure, and for these band-width reduction and the like are preferred. Good luck with HiGHS, I look forward very much to seeing your fully-developed QP solvers ... and a healthy comparison with those in GALAHAD! |
Beta Was this translation helpful? Give feedback.
-
|
@odow Is there a reason why you suggest building Metis as a separate library, rather than building it as part of libhighs? Is it to keep libhighs MIT licensed? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This is an issue for @filikat and @galabovaa.
At JuMP-dev '25, @amontoison and I were discussing HiGHS, METIS, compilation, and distribution.
Our conclusion is that the easiest path forward is for HiGHS to vendor the source code of GKLib and METIS into ERGO-Code/HiGHS (or ERGO-Code/METIS).
This would let you choose the version of METIS to use, you could delete much of the code that is unused, and you could carry the various patches that you need.
To avoid conflicts with other libraries that use METIS, you should:
libmetistolibmetishighshighs_) to all symbols so that there are no conflicts between the symbols of libmetishighs and libmetis.The main reasons for vendoring METIS are:
The main reason against vendoring METIS is the license. The resulting binaries would be Apache instead of MIT, but building without HiPO would still let you have a MIT licensed binary.
Beta Was this translation helpful? Give feedback.
All reactions