Graph state connections about quisp HOT 2 OPEN

Notes from early June:

@sara @michal Hajdusek @Cocori and I had a meeting (virtual, of course) this morning.
We have begun working a little bit on graph state links, as epitomized
in Pau Hilaire’s paper (https://arxiv.org/pdf/2005.07198.pdf). This
builds on work by Azuma-san
(https://www.nature.com/articles/ncomms7787) and earlier work in the
Economou group
(https://journals.aps.org/prx/abstract/10.1103/PhysRevX.7.041023).
(Paul’s paper is pretty self-contained, if you’re just starting to
read about this topic it’s fine to start there.)
We are trying to work out RuleSets for how to make this happen.
A few items from our meeting:

• Terminology: Let’s use “vertex” to mean “photon in a graph state,”
  so we don’t get confused with “node”, which we use to refer to
  hardware.
• A quick-and-dirty approach would be to just use Eq. 4 in Paul’s
  paper to set a probability for link success.
• Our real goal, though, is to simulate the full thing. Actually,
  it’s really to design a link and the communication protocols to
  make this happen.
• In Fig. 2, we don’t yet fully understand everything, but we think
  qubits Q3 and Q1 are operating in parallel, generating their
  subtrees, and then Q2 is used to merge those subtrees. Is that
  right? (We’re still reading the paper, so it might be written there
  somewhere.)
• Oooh, tomography on the link will be difficult. (We looked at a
  recent paper out of the Jian-Wei Pan group, but not sure it’s of
  much help here.)
• If end nodes Alice and Bob are having trouble violating a CHSH
  inequality (or making high-fidelity QKD key or whatever end-to-end
  check we’re doing), how will they debug that? Do we need link-level
  tomography?
• I was originally thinking that this choice of using repeater graph
  states (RGS) could be done in isolation on a single link, without
  affecting neighboring links. However, we’ve now realized how much
  this approach is intended to be a multi-hop connection, even though
  the final output is an end-to-end physical Bell pair. I now think
  it makes sense to treat the choice of link as something that happens
  across a network, though there might be a border router that
  performs interoperability tasks, a la Shota.
  (https://journals.aps.org/pra/abstract/10.1103/PhysRevA.93.042338)
  Thus, RuleSets might need to be multihop, rather than just on the
  physical link.
• Back when we first began the QuISP journey, we spent a lot of time
  talking about whether BSA (Bell State Analyzer) nodes are
  first-class nodes, or if they are just part of the link. Eventually
  we settled on them being just part of the link: all they have to do
  is measure the photons and report the results (or failure to
  receive) to the ends of the link; no node any farther away needs to
  know anything about the existence of the BSA.
  Implementing RGS (repeater graph state)-based connections is going
  to require substantially rethinking this. We are going to have to
  create a “Generalized Bell State Analyzer” (GBSA) or “Advanced BSA”
  (ABSA) or something like that. The ABSA (I think I like that name
  better) has to make decisions in real time, based on prior
  results. As such, the ABSA will need RuleSets of its own.
  Moreover, in this connection architecture, the repeater nodes with
  the matter qubits are completely uninvolved in operation after
  generating the RGS. In a sense, this flips the network architecture
  upside down; the nodes with matter qubits are more like midpoint
  sources and the ABSA is more like the repeater. The ABSA will have
  to communicate with endpoints to indicate success/failure and Pauli
  frame corrections. Those RuleSets will have to be developed for the
  end-to-end (or at least end-to-border-router) connection, so there
  will be substantial work to be done here...
  This is going to be more coding and more rethinking of networks than I
  had originally hoped, but I think it’s tractable and I think we will
  learn a lot about the feasibility of RGS-based connections as a
  result.

I think the Figure numbers refer to Paul's arXiv paper:
https://arxiv.org/abs/2005.07198

Paul Hilaire 6:24 PM

• I agree with the first points.
• On the Fig. 2, Q3 is used as a quantum emitter that produces photons and Q1 and Q2 are used as "anchors" to "store" the entanglement with the photons produced by Q3. Q2 is used to store the tree branches and Q1 the full arm (full tree + outter qubit). Then you measure them to produce the photons.
  One should note that with a RuleSet approach, there is a problem as the outter qubit should be measured first to determine then the measurement basis of the other photons in the tree, but the outter qubit is the last one to arrive to the node. This problem can be solved by adding another quantum emitter Q4 that only purpose is to produce the outter qubits and connect them to the graph structure. This way we can force the outter photons to arrive first.
• I don't fully understand what is meant by tomography for this purpose?
• I don't really understand that neither, but if the goal is to improve the Bell pair fidelity, we should add purification to the scheme, which is not really straightforward to implement with all photonic repeaters (at least to me)
• I agree that all-photonic repeaters kind of impose to be used next to other all-photonic repeaters otherwise they are not completely useful. But you can still assume that it can be connected to a larger network if you store the entanglement into quantum memories at interface nodes.
• Also, I've just remembered that in the paper from Mihir Pant (Pant et al. PRA 2017) on RGS, the inner qubits are kept inside the source node and only the outter qubits are sent. This might make the simulation easier to deal with as you can keep the BSA as it is and you reduce the actual number of sent photons (which is good for channel capacity). However, it requires classical signaling (but its repetition rate performance are still not limited by it as for a memory-based quantum repeater) and it requires the inner photons to be stored into the source nodes. These inner photons are substantially different from the Stationnary qubits already developped in QUISP as they can be lost (you need to keep them in a fiber loop until the classical signaling come back to know in which basis they should be measured. That may be an interesting alternative to simplify this simulations (instead of actually sending thousands of photons to produce a Bell pair, you actually send around 15 photons and keep the rest inside the node which maybe faster to simulate). The performances are slightly worse in terms of rate per matter qubits as the inner photons are kept at least twice longer (due to the classical signaling) but I think it is manageable. The channel capacity is "artificially" increased a lot (artificially because you effectively use fibers kept inside the nodes to store the photons...). This was a claim of Pant's paper which I do not completely agree with.

from quisp.

6/10 graph state repeater meeting (Sara, Michal, cocori):

Things we realized:

• maybe not as related to all-at-once entanglement swapping as I
  thought...
  #82
• The Advanced Bell State Analyzer (ABSA) will need QRSA software:
  • RuleEngine (RE) for sure
  • ConnectionManager (CM) for sure
  • RealTimeController (RTC) probably, but it doesn't do much now
  • others may be optional
  • see
    https://github.com/sfc-aqua/quisp/blob/master/quisp/networks/qrsa.ned
    https://github.com/sfc-aqua/quisp/blob/master/quisp/modules/RuleEngine.cc
  • Hardware model should build off of BSA:
    https://github.com/sfc-aqua/quisp/blob/master/quisp/modules/BellStateAnalyzer.cc
    others, too...
• multi-hop timing synchronization is going to be tough
  Probably related to MSM links:
  #15
• We want the four-qubit repeater nodes version that Paul mentioned
  above, so that we can feed the photons to the ABSAs in the right
  order.

Tasks that need to be done:

• Design simple RuleSets for repeater nodes
• Design simple RuleSets for ABSA nodes
• Design simple RuleSets for EndNodes w/ memory (making only half
  of graph states and sending it)
• Create ABSA node type (not sure how much work this is)
• Adapt QRSA software (qrsa.ned & C++ files as necessary) for ABSA
  (create absasa.ned?)
• figure out how to synchronize nodes along the path
• Create a simple .ned file for example network
• Design simple RuleSets for memoryless Measurement-Only nodes
  (optional, on down the line)

from quisp.