QuantumCliffordJuMPExt: compute the minimum distance of QLDPC using Mixed Integer Programming

[Fe-r-oz]

This PR implements the Mixed Integer programming (MIP) approach to compute the minimum distance of QLDPC using GNU's Linear Programming Kit. This method is used by Panteleev and Kalachev and by Bravyi et. al.. The latter reference mentioned that this MIP approach was originally developed in 2011 and used in this reference

This PR allows the users to compute the minimum distance with ease and also provide the necessary documentation along with the relevant modern usecases. The tests have been conducted in #435

ILP/MILP methods: https://quantumcomputing.stackexchange.com/questions/37289/compute-the-exact-minimum-distance-of-a-qecc-with-integer-linear-programming-met

P.S. Mixed Integer Programming (MIP) or mixed integer linear program refer to same thing in the literature, in this context.

Edit:

• The code is properly formatted and commented.
• Substantial new functionality is documented within the docs.
• All new functionality is tested.
• All of the automated tests on github pass.
• We recently started enforcing formatting checks. If formatting issues are reported in the new code you have written, please correct them.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.42%. Comparing base (6065fab) to head (e40b4b3).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #439      +/-   ##
==========================================
+ Coverage   82.82%   83.42%   +0.60%     
==========================================
  Files          70       73       +3     
  Lines        4651     4808     +157     
==========================================
+ Hits         3852     4011     +159     
+ Misses        799      797       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Fe-r-oz]

Please help review this PR, thank you :)

Thanks to GNU for open-souring GLPK. I have tested all the instances of 2bga codes using distance and added other tests for correctness. Many more tests are in #435. Referring to #353 as it's related a issue. This PR aims to provide the first reasonable step. This MIP method is used by Panteleev and Kalachev and by Bravyi et. al.. This MILP method that Bravyi used was also asked on stack exchange. The end goal is to be able to compute minimum distance of QECC/QLDPC codes with n being $10^3$ or $10^4$: QDistRnd or MaxSAT solvers or upcoming algorithms appear to be helpful for that. There is a lot more work to be done in this direction. I will be happy if this PR is one of my PRs you are most excited about, along with in-place Ted's Pauli measurement algorithm PR. :)

Possible Future TODOs include:

• More performance optimizations if possible
• comparison with distance solvers from stim.
  • It uses Microsoft's z3 SAT solver. This method formulate task the problem into maxSAT problem. Julia does have the z3.jlbinding! stim also uses pysat for maxSAT problem.
  • stim also uses pysat to convert distance-finding problem into a maxSAT problem
• comparison with QDistRnd Package from GAP: we can use Oscar to directly use QDistRnd package. User would have to provide the matrix is MTX format.
• integrate latest solvers: Grassl, Eric and others are working towards it and have some papers in this new directions
• implement minimum distance solvers in pure Julia
• Benchmark Lifted product codes Lifted and lifted product codes via Hecke's GroupAlgebra #356
• Benchmark 2BGA codes with finitely presented groups and with Direct product of General Groups, e.g. direct product of two finite groups using Oscar add QuantumCliffordOscarExt to provide convenient API for finitely presented groups via specific group presentation #400
• Benchmark Haah's cubic code using abelian group ℤ₃ˣ³ via Hecke's Group Algebra #388,
• Benchmark Coprime Bivariate Bicycle code via Hecke's Group Algebra #378
• Benchmark Multivariate Bicycle code via Hecke's Group Algebra #381
• Benchmark Implementing Bivariate Bicycle Codes using 2BGA as the parent via Hecke's Group Algebra #399
• Benchmark add tests and examples of Cₘ × C₂ 2BGA codes #392
• Benchmark Honeycomb color code via Hecke's Group Algebra #436
• Benchmark more examples of Bivariate Bicycle codes #441
• Benchmark Haah's cubic code via LP construction method #442
• Benchmark color codes with varying distances according to formula
• Cross-check the minimum distance of La-Cross codes in [[2n², 2k², d]] and [[(n - k)² + n², k², d]] La-cross quantum LDPC codes #471

[Krastanov]

This is really interesting and deserving of a bounty.

Regrettably there are a few merge conflicts related to the doc fixes in an earlier PR. Could you fix those?

I also probably would suggest looking into a slightly different API, or at least some easier way to support independent solvers. But that can be discussed after the first round of review.

[Fe-r-oz]

Some easier way to support independent solvers.

That's a great suggestion (solver = ). I have been reading the JuMP discourse recently about MIP. User can use HiGHs.jl, GLPK.jl, the underlying solver for these is free, but Gurobi.jl or CPLEX.jl have some underlying solver that require obtaining license. If people want to use closed sourced solvers for faster performance maybe, we can give them that choice. In addition, I found these posts interesting:

• https://discourse.julialang.org/t/is-glpk-still-maintained-relevant/116950/4
• https://discourse.julialang.org/t/fastest-open-licensed-solver-for-integer-problems/17440
• https://discourse.julialang.org/t/error-with-highs-independent-parallel-solves/96048/2
• https://stackoverflow.com/questions/502102/best-open-source-mixed-integer-optimization-solver

From Gurobi.jl documentation: The underlying solver is a closed-source commercial product for which you must [obtain a license](https://www.gurobi.com/). Free Gurobi licenses are available for [academics and students](https://www.gurobi.com/academia/academic-program-and-licenses/).

A̶s̶ a̶ f̶u̶t̶u̶r̶e̶ T̶O̶D̶O̶:̶ C̶e̶r̶t̶a̶i̶n̶ M̶L̶E̶ d̶e̶c̶o̶d̶e̶r̶s̶ r̶e̶q̶u̶i̶r̶e̶ M̶I̶P̶ s̶o̶l̶v̶e̶r̶s̶ a̶s̶ w̶e̶l̶l̶. T̶h̶i̶s̶ w̶e̶e̶k̶, [̶C̶o̶r̶r̶e̶l̶a̶t̶e̶d̶ d̶e̶c̶o̶d̶i̶n̶g̶ o̶f̶ l̶o̶g̶i̶c̶a̶l̶ a̶l̶g̶o̶r̶i̶t̶h̶m̶s̶ w̶i̶t̶h̶ t̶r̶a̶n̶s̶v̶e̶r̶s̶a̶l̶ g̶a̶t̶e̶]̶(̶h̶t̶t̶p̶s̶:̶//a̶r̶x̶i̶v̶.o̶r̶g̶/p̶d̶f̶/2̶4̶0̶3̶.0̶3̶2̶7̶2̶)̶ a̶p̶p̶e̶a̶r̶e̶d̶ o̶n̶ a̶r̶X̶i̶v̶, a̶n̶d̶ i̶t̶ u̶s̶e̶d̶ M̶L̶E̶ d̶e̶c̶o̶d̶e̶r̶ t̶h̶a̶t̶ u̶s̶e̶ M̶I̶P̶ a̶p̶p̶r̶o̶a̶c̶h̶. T̶h̶i̶s̶ p̶a̶p̶e̶r̶ r̶e̶f̶e̶r̶e̶n̶c̶e̶s̶ t̶h̶e̶ s̶a̶m̶e̶ 2̶0̶1̶1̶ p̶a̶p̶e̶r̶ t̶h̶a̶t̶ i̶n̶t̶r̶o̶d̶u̶c̶e̶d̶ t̶h̶e̶s̶e̶ M̶L̶E̶ d̶e̶c̶o̶d̶e̶r̶s̶ u̶s̶i̶n̶g̶ m̶i̶x̶e̶d̶-̶i̶n̶t̶e̶g̶e̶r̶-̶p̶r̶o̶g̶r̶a̶m̶. The MLE decoder if we implement it using Linear Programming approach is 1000x slower than Chromobius and 300x slower than NN decoder (Reference), so I don't think that going within LP formulation (MLE decoders using LP) approach sounds appealing.

We can allow to user to select from these solvers (based on recent trends):

• SCIP.jl (open-source)
• HIGHS.jl (open-source)
• GLPK.jl (open-source) ; not recommended by Oscar
• Gurobi.jl (~open-source)
• Cbc.jl (maybe this as well) (~open-source)

Edit:

HiGHS solver will continue to get improvements for MIP problems:

• benchmarks: https://app.slack.com/client/T68168MUP/C6FGJ8REC
• https://jump.dev/announcements/open-energy-modeling/2024/09/16/oem/

[Fe-r-oz]

Thank you very much for your valuable feedback. The code is now independent of any specific MIP solver.

I chose HiGHS as the default MIP solver over GLPK because of the ongoing collaboration between JuMP and HiGHS to enhance the HiGHS.jl package. This makes HiGHS a more forward-looking choice.

I have not added SCIP.jl as a solver yet due to dependency issues. Specifically, SCIP.jl relies on polymake, which conflicts with other dependencies like Hecke or Nemo. Addressing this is on my future TODO list.

Regarding multi-threading, GLPK does not support it, and HiGHS currently has some issues with independent parallel solves: JuliaLang Discourse discussion. Once these issues are resolved, we can revisit adding multi-threading support.

I look forward to hearing your thoughts and suggestions regarding the API. Thank you once again!

[Fe-r-oz]

I turned this PR into draft to add a better error message for non-CSS codes. This was inspired from a totally random but useful thought. Apologies I turned the PR into draft. A Future TODO would be to add more documentation about two new use cases for MIP solvers from latest papers.

The algorithm by default calculates the minimum Hamming weight $d_{Z}$ for the Z-type logical operator (as originally done in the Bravyi's paper). The minimum distance for X-type logical operators is the same. I have actually tested this but we don't really require logical_operator_type parameter, we can live by either calculating minimum Hamming weight $d_{Z}$ for the Z-type logical operator or $d_{X}$ for the X-type logical operator. It might be stupid of me to calculate $d_{Z}$ and $d_{X}$ both based on user input, they both provide same result.

So, testing is somewhat stringent in minimum_distance.jl. Maybe for some performance gains and cleanup, the logical_operator_type can be removed. During implementation, I thought I should definitely test whether minimum distance for X-type logical operators is the same minimum distance for Z-type logical operators as correctness check.

[Fe-r-oz]

Please help review this PR, thank you!

[Fe-r-oz]

I also probably would suggest looking into a slightly different API, or at least some easier way to support independent solvers

Thank you once again for this helpful insight. After some more introspection, I am turning this back to draft status. This is because today, I came across the latest JuMP discourse post and insightful comment by Oscar: Let the user choose which solver to use. There is no need to add it to the Project.toml. Adding solvers to the Project.toml means that every user installs all of the solvers, even if they never end up using them, and it runs into license issues like the one you are experiencing.

This reminded me of your insightful comment. I think this is what you meant by "easier way to support independent solvers"! It seems that I didn't understood it correctly. Currently, I have I added QuantumCliffordJuMPExt = ["GLPK", "HiGHS", "JuMP"] in project.toml but everything works fine and okay 🙂 I have used opt = solver.Optimizer with default solver = HIGHS, and then I call model = Model(opt; add_bridges = false).

Based on the insights gathered, the user can decide which solver to pass as solver.Optimizer? That way, there would be no need to have GLPK, HiGHS or any other solver in the project.toml.

My apologies for the mistake! I'm glad that your insightful comment reminded me of this!

[Fe-r-oz]

I also probably would suggest looking into a slightly different API, or at least some easier way to support independent solvers

The implementation is now independent of solvers, both closed source or open source MIP solvers can now be used!

This PR is now ready for review, Thank you!