[WIP] adding OMEinsumContractionOrders results

[GiggleLiu]

I use OMEinsumContractionOrders to find the optimal contraction order, the best space complexity I can get is 52.

running circuit sycamore_53_20_0, method = KaHyParBipartite{Int64, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}}(52, 0.0:0.005:0.8, 40, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}(OMEinsum.ContractionOrder.MinSpaceOut(), 10))
(tc, sc) = (78.00155118359883, 52.0)
running circuit sycamore_53_20_0, method = SABipartite{Int64, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}}(52, 50, 0.1:0.2:14.9, 1000, 40, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}(OMEinsum.ContractionOrder.MinSpaceOut(), 10), :random)
(tc, sc) = (76.60214859993935, 52.0)
running circuit sycamore_53_20_0, method = GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}(OMEinsum.ContractionOrder.MinSpaceOut(), 10)
(tc, sc) = (84.20945470788618, 64.0)
running circuit sycamore_53_20_0, method = TreeSA{Int64, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}}(20, 0.01:0.05:14.96, 10, 50, 1.0, 0.2, :greedy, GreedyMethod{OMEinsum.ContractionOrder.MinSpaceOut}(OMEinsum.ContractionOrder.MinSpaceOut(), 1))
┌ Warning: target space complexity not found, got: 52.0, with time complexity 71.00176664769552, read-write complexity 58.290885386883325.
└ @ OMEinsumContractionOrders ~/.julia/dev/OMEinsumContractionOrders/src/treesa.jl:94
(tc, sc) = (71.00176664769552, 52.0)

Part of the code. YaoToOMEinsum has not been public yet. So you might not be able to reproduce the result at this moment. I need to polish this package until it can be good enough to open source. So you do not need to merge this PR hurry.

[brenjohn]

Woah, those results look really good :)

I haven't read Kalachev's paper on using simulated annealing for this yet but it's interesting how well treeSA does compared to the others. How long did it take to run with the given number of iterations do you know?

[GiggleLiu]

The timing for these contraction order finders:

  "method"           => "GreedyMethod"
  "time"             => 0.687117

  "method"           => "KaHyParBipartite"
  "time"             => 10.2938

  "method"           => "SABipartite"
  "time"             => 4.6158

  "method"           => "TreeSA"
  "time"             => 89.829

Compiling time is not excluded, so this is just a crude estimation.

[brenjohn]

Thanks @GiggleLiu that's interesting.

I think it would be nice to try use OMEinsumContractionOrders in QXTools. I originally thought about adding several methods along side flowcutter and eventually implementing something like Johnny Gray's hyper optimized method as that approach strikes me as the best for generic networks.

Do you know if anything similar is planned for OMEinsumContractionOrders? or if there are any plans to include slicing as a feature?

[GiggleLiu]

Slicing is not planned, but is very likely to be added in the future when I or someone needs it. The goal of OMEinsumContractionOrders.jl is to optimize the OMEinsum.jl contraction code. It would be great if OMEinsum.jl as a tensor network contractor is useful in your project. One of possible ways to proceed is:

I make you one of the collaborators of OMEinsumContractionOrders, or you create another package that implements the optimize_code interface. Then you can keep adding more methods like FlowCuter and features like slicing while keeping it compatible with OMEinsum ecosystem. BTW: The TreeSA method is easy to extended for slicing.

TreeSA paper is released in Aug this year, so I believe this is the state of the art. The hyper optimized paper contains a lot interesting methods too, but I am not sure they are optimal. We implemented the KaHyParBipartite algorithm, which is one of the best methods in the paper (Hyper-Par).

[GiggleLiu]

One more comment, the standard tensor network representation has a drawback that it has to introduce some delta tensors. As a result, the treewidth can increase significantly. For example, in one of my application, the treewidth of a king's graph of size LxL is 3L (standard notation) v.s. L+2 (einsum notation). I am worrying that part of your overhead comes from the use of delta tensors. Einsum as a hypergraph version of tensor network is easier to find a good contraction order.

BTW: if you are interested in converting Yao to OMEinsum contraction code, I can release a public version first (I just need to discuss with some other people first), it is only 129 lines of code...

[GiggleLiu]

UPDATE: we have made YaoToEinsum.jl public here: https://github.com/QuantumBFS/YaoToEinsum.jl

[brenjohn]

We are actually already using OMEinsum.jl in one of our packages (QXContexts.jl) to perform tensor contractions. I think 'OMEinsumContractionOrders.jl' might not have been available when we started working on QXTools, otherwise we probably would have used it already :D

I'm still not sure where the neatest place is for slicing. We are aiming to run circuit simulations on different clusters and one thing we wanted was a workflow were we use QXTools.jl to create a set of simulation files describing the simulation (including the contraction order) and then use QXContexts.jl to execute the simulation on a cluster. The hope was that the information in the simulation files would be hardware agnostic so we can reuse them on different machines. However, slicing is in some sense not hardware agnostic since you only want to slice if the network contraction does not fit in memory. I'm thinking QXTools could use OMEinsumContractionOrders to find a contraction order to write to the simulation files and then maybe QXContexts could have a feature or use another package to slice the order and run local optimizations after each slice.

I think to proceed, I'll create a another package to prototype it (and I can try implement the 'optimize_code' interface for flowcutter also) and we can revisit it when I have a better idea of how I'd like to organize it.

[GiggleLiu]

I'll create a another package to prototype it (and I can try implement the 'optimize_code' interface for flowcutter also) and we can revisit it when I have a better idea of how I'd like to organize it.

Sounds good 👍🏾