src/sage/graphs/generic_graph.py: work around doctest hang

[orlitzky]

One doctest in this file is "hanging" on ARM64 and RISC-V as GLPK tries courageously to solve a MIP. A tweak to the solver options allows this problem to be solved on those two architectures without affecting any others. This is unlikely to solve the general problem, but it may buy us some time.

[github-actions]

Documentation preview for this PR (built with commit f592087; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[dcoudert]

This should be done only when the solver is glpk. I have cplex by default and get

sage: G.edge_disjoint_spanning_trees(2, solver='cplex')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[5], line 1
----> 1 G.edge_disjoint_spanning_trees(Integer(2), solver='cplex')

File ~/sage/src/sage/graphs/generic_graph.py:7373, in GenericGraph.edge_disjoint_spanning_trees(self, k, algorithm, root, solver, verbose, integrality_tolerance)
   7360 # We now solve this program and extract the solution
   7361 try:
   7362     # The MIP approach with GLPK is prone to compiler and
   7363     # optimization-level weirdness on some hardware:
   (...)
   7371     # that it probably hasn't badly broken some other use
   7372     # case.
-> 7373     p.solver_parameter("presolve_intopt", False)
   7374 except KeyError:
   7375     # Must not be using GLPK...
   7376     pass

File ~/sage/src/sage/numerical/mip.pyx:2863, in sage.numerical.mip.MixedIntegerLinearProgram.solver_parameter()
   2861         return self._backend.solver_parameter(name)
   2862     else:
-> 2863         self._backend.solver_parameter(name, value)
   2864 
   2865 cpdef sum(self, L):

File sage_numerical_backends_cplex/cplex_backend.pyx:1632, in sage_numerical_backends_cplex.cplex_backend.CPLEXBackend.solver_parameter()

ValueError: This parameter is not available.

[orlitzky]

This should be done only when the solver is glpk.

Yeah I tried, but I missed a few exceptions. I've added NotImplementedError and ValueError to the list.

[orlitzky]

@collares can you please test this on aarch64? I think it will work, but for the commit message to not be a lie, it has to be attempted.

[dcoudert]

you can check the backend.

sage: from sage.numerical.mip import MixedIntegerLinearProgram
sage: from sage.numerical.backends.glpk_backend import GLPKBackend
sage: p = MixedIntegerLinearProgram(maximization=True)
sage: p.get_backend()
<sage_numerical_backends_cplex.cplex_backend.CPLEXBackend object at 0x13e0c14c0>
sage: isinstance(p.get_backend(), GLPKBackend)
False
sage: p = MixedIntegerLinearProgram(maximization=True, solver='glpk')
sage: p.get_backend()
<sage.numerical.backends.glpk_backend.GLPKBackend object at 0x13e042460>
sage: isinstance(p.get_backend(), GLPKBackend)
True

[orlitzky]

you can check the backend.

Much easier, thank you.

[orlitzky]

CI says it's OK.

There's a risk that I've made things worse on "normal" systems in some way that we don't yet measure, but we could always revert it if random failures start popping up on x86_64 machines.

[dcoudert]

LGTM.

[dcoudert]

If other random issues occur, we can either revert this change, or prevent using some solvers for this method, or...

Unfortunately, I will not be able to work on the combinatorial algorithm in the forthcoming months. I can be a project for next GSoC if we find a strong student. It's a hard work.

[orlitzky]

Thanks.

After I posted the GLPK bug report, I was contacted by one of the HiGHS developers who basically asked, "why are you still using GLPK?!?!" It's a fair question. HiGHS is able to solve this problem, and is actively maintained by a paid developer.

HiGHS already has a python interface, so it shouldn't be too hard to create a sage-numerical-backends-highs package like we have for CPLEX. It also doesn't look too hard to package HiGHS for linux/homebrew/conda/etc, which makes it a strong candidate for replacing GLPK as the default IMO.

[dcoudert]

indeed. this seems a very good idea. We already have a backend for scip. We can certainly work on a backend for HiGHS and then drop glpk. You can open an issue to monitor this task.
In the long term we will have to improve all backends for faster interactions. We currently wasting a lot of time passing models to solvers, we don't have access to dual variables, we cannot do column generation, etc.

[collares]

Can confirm that the relevant test no longer hangs on aarch64-linux with this patch

[orlitzky]

Great, thank you.