DataStructures.PriorityQueue does not properly resolve ties (see JuliaCollections/DataStructures.jl#498 ), hence we are using a slow simple Vector implementation currently (since #69 ). Implementing (and benchmarking) a potential new FIFO-tie-breaking priority queue might greatly increase tagging performance.

Frequently we do

slot, tag = query(...)
pop!(slot, tag)
tag!(slot, tag)

This is fine as long as the pop! and tag! are next to each other, but it is prone to race conditions if there is a @yield between them. An atomic version of this operation would be very valuable.

An example based on #90 should be added to the docs

Project: Improve Makie visualization capabilities [$200]

We use Makie for visualizing the state of a simulated network. We can visualize the state of registers, the content of these registers, some tag information, etc. There is much more information that can be tracked visually though. This project is about fleshing out these visualization features.
This list of issues can be a useful guide to features that need to be implemented, but you should feel free to suggest deviations from these guidelines if you have different ideas -- however the scope of the project should be set at the start of the project, e.g. by discussing it in this thread.

Required skills: Understanding of the Makie plotting library

Reviewer: Stefan Krastanov

Duration: 1 month

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

Added spin-spin density matrices for entanglement generated using mid point swap using Quantum Optics package support; Look at the section 1B2-1B3 Eqn. 1-9

@time @eval using QuantumOptics
@time @eval using QuantumSymbolics
using LinearAlgebra
base=SpinBasis(1//2);
k0=spindown(base);
k1=spinup(base);
k0d=dagger(k0);
k1d=dagger(k1);

function spspstate_single(eA,eB,gA,gB,edet=1,Pd=0,vis=1,eps=0)
    @assert eA>0 && eA<=1 && eB>0 && eB<=1 && edet>0 && edet<=1
    @assert Pd>=0 && Pd<1
    @assert vis>0 && vis<=1 && eps>=0 && eps<1
    @assert gA>=0.5 && gA<1 && gB>=0.5 && gB<1
    visMod=vis*exp(-eps)
    # Components without dark clicks
    r22a=0.5*gA*(1-gB)*eB*edet*(k0⊗k1)⊗(k0d⊗k1d)
    r33a=0.5*gB*(1-gA)*eA*edet*(k1⊗k0)⊗(k1d⊗k0d)
    r23a=0.5*sqrt(gA*gB*eA*eB*(1-gA)*(1-gB))*edet*visMod*(k0⊗k1)⊗(k1d⊗k0d)
    r32a=0.5*sqrt(gA*gB*eA*eB*(1-gA)*(1-gB))*edet*visMod*(k1⊗k0)⊗(k0d⊗k1d)
    r44a=0.5*edet*(1-gA)*(1-gB)*(eA+eB-2*edetA*eB*e)*(k1⊗k1)⊗(k1d⊗k1d)
    rho=(1-Pd^2)*(r22a+r33a+r23a+r32a+r44a);
    # Components with dark clicks
    if Pd>0
        r22b=gA*(1-gB)*(1-eB*edet)*(k0⊗k1)⊗(k0d⊗k1d)
        r33b=gB*(1-gA)*(1-eA*edet)*(k1⊗k0)⊗(k1d⊗k0d)
        r11b=gA*gB*(k0⊗k0)⊗(k0d⊗k0d)
        r44b=(1-gA)*(1-gB)*(1-etaA*edet)*(1-etaB*edet)*(k1⊗k1)⊗(k1d⊗k1d)
        rho = rho + Pd*(1-Pd)*(r22b+r33b+r11b+r44b)
    end
    return rho
end 

function spspstate_dual(eA,eB,edet=1,Pd=0,vis=1)
    @assert eA>0 && eA<=1 && eB>0 && eB<=1 && edet>0 && edet<=1
    @assert Pd>=0 && Pd<1
    @assert vis>0 && vis<=1
    # Components without dark clicks
    r22a=0.25*eA*eB*edet^2*(k0⊗k1)⊗(k0d⊗k1d)
    r33a=0.25*eA*eB*edet^2*(k1⊗k0)⊗(k1d⊗k0d)
    r23a=0.25*eA*eB*(edet^2)*(vis^2)*(k0⊗k1)⊗(k1d⊗k0d)
    r32a=0.25*eA*eB*(edet^2)*(vis^2)*(k1⊗k0)⊗(k0d⊗k1d)
    rho=(1-Pd^2)*(r22a+r33a+r23a+r32a)
    # Components with dark clicks
    if Pd>0
        rB=0.5*(1-Pd)*edet*(eA+eB-2*eA*eB*edet)+Pd*(1-eA*edet)*(1-eB*edet)
        rho= rho + rB*((k0⊗k1)⊗(k0d⊗k1d)+(k1⊗k0)⊗(k1d⊗k0d)+(k0⊗k0)⊗(k0d⊗k0d)+(k1⊗k1)⊗(k1d⊗k1d))
    end
    return rho
end

The docstrings for some StateZoo objects get rendered redundantly.

See e.g. https://quantumsavory.github.io/QuantumSavory.jl/dev/API_StatesZoo/#QuantumSavory.StatesZoo.DualRailMidSwapBellW

Due to

Julia's documenter is smart enough to use per-parameter docstrings. Move the current docstrings in per-parameter docstrings.

If that breaks the @withmetadata macro, file an issue about it and leave the PR open for later -- no need to invest too much time on it.

@Abhishek-1Bhatt , could you reach out to Prajit (feel free to cc me) in order to get the projenitor Mathematic files for the matlab files in these two locations:

• https://github.com/QuantumSavory/QuantumSavory.jl/blob/master/src/StatesZoo/single_dual_rail_midswap/entanglement_swap_with_emissive_memories/readme.md
• https://github.com/QuantumSavory/QuantumSavory.jl/blob/master/src/StatesZoo/zalm_pair/readme.md

Currently these are based on machine generated matlab files, so we can not actually recreate and review the work. That threatens the scientific record, as if a mistake is found somewhere we would not be go to the origin of the code and find the source of the mistake.

Ask Prajit for clean documented mathematica notebooks that were used to create the matlab files, save them in git in the same folder with clear filenames, and add a mention to both readme files that the mathematic files are the source of the matlab code which was then manually converted to julia.

Occasionally a query(...,unlocked=true) will return false due to only the lock. We need to be able to wait on certain queries and be given a slot at the earliest time at which they become available

With #106 merged we now support filo and fifo order for query results. But if we have multiple slots, the order will be by slot index, not by time of insertion. We need to provide time of tagging for this to work.

In order to have entanglement id's local to each RegisterNet automatically used inside tag! without changing the api, we need to have a new Simulaton type as discussed in #114 (comment)

Project: Waiting on register events [$800]

Many of the protocols implemented in this simulation library have the form:

while True:
    @yield timeout(fixed_wait_time)
    if check_whether_a_property_is_true()
        do_something_important()
    end
end

It would be much better if there is an option for them to be written as

while True:
    @yield waiting_for_register_or_slot_state_to_change()
    if check_whether_a_property_is_true()
        do_something_important()
    end
end

That can be relatively easily implemented by creating the necessary resource objects on which the protocols can listen (APIs provided by ConcurrentSim) and then hooking these features in the register API (e.g. initialize, apply!, traceout!, etc). We probably will want different types of "waiters" for different types of changes that might happen. This will be necessary also for changes related to tagging and untagging, or receiving messages over a channel. Some attention will need to be paid to making sure that all these new checks do not cause severe performance penalties to code that does not use them.

To win this bounty, such an API would need to be implemented, incorporated in some of the examples that already exist, enabled in already existing protocols, documented, and tested. There should also be a new example that compares the performance of a protocol that uses the @yield timeout versus one that uses the @yield wait_for_register_change.

Required skills: Understanding of ResumableFunctions.jl and ConcurrentSim.jl

Reviewer: Stefan Krastanov

Duration: 2 months

Publication: In the next 2 years we plan to release a paper in a selective journal about this software. Contributing to this issue would deserve a co-authorship status on such a paper (if the contributor so desires)

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Project: "Improve static analysis tests with JET" [$200]

We use JET for static analysis of the codebase. To claim this bounty, fix 2/3 of the reported warnings. Some of them are false positives that can be removed with extra type annotation. Some of them are due to dependencies, in which case you can simply blacklist the dependency (as already done). See the test_jet.jl test file and the JET CI run for the current state of affairs.

Required skills: General Julia and JET skills.

Reviewer: Stefan Krastanov

Duration: 1 month

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

using QuantumSavory

ra = Register(1)
rb = Register(1)

st = L0⊗X1

initialize!((ra[1], rb[1]), st)
ra.staterefs[1].state[]

apply!(rb[1], H)
ra.staterefs[1].state[]

Here, the initial state L0⊗X1 should be transformed to L0⊗L0 when Hadamard is applied to the 2nd qubit, but instead we get X1⊗X1

Project: Aqua static analysis [$200]

We run Aqua.jl static analysis during CI for this library, but currently, we have disabled some checks, as they raise too many errors. This bounty is awarded for fixing these issues and enabling these checks. The bounty might require upstreaming some work from here into QuantumInterface.jl or other packages.

Required skills: Generic Julia skills.

Reviewer: Stefan Krastanov

Duration: 1 month

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

after "default" channels and quantum channels get in #69 , we need to start supporting arbitrary tagged channels and creation of tagged channels based on pre-existing channels

Project: "Tensor Networks Backend" [$400]

This project depends on first completing QuantumSavory/QuantumSymbolics.jl#63

This simulation library can easily work with state vectors and stabilizer tableaux, thanks to the existence of QuantumSymbolics backends for them. To complete this project the contributor will need to plug in a tensor network backend, so that simulations can be performed using tensor network numerical representations. Some of the currently existing examples already perform simulations using both stabilizer states and state vectors. These examples will need to be updated to include tensor network simulations as well. A new example of a simulation that would be too expensive to run without tensor networks would be necessary as part of this contribution, in order to showcase and document the new functionality.

Required skills: Familiarity with tensor networks and with the QuantumSymbolics package.

Reviewer: Stefan Krastanov

Duration: Can be reserved for 2 months and potentially extended.

Publication: In the next 2 years we plan to release a paper in a selective journal about this software. Contributing to this issue would deserve a co-authorship status on such a paper (if the contributor so desires)

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

In #81 we now have a SwapperProt. It has a nodeL and nodeR properties which are then used by query to decide whether a pair of local slots are a valid target for a swap. It is done by findswapablequbits.

Currently, this is tested only for a long chain of repeaters, using the default "wildcard" values for these properties.

More complicated setups should be tested.

• step 0

First, we need to make findswapablequbits sufficiently general. We need to support custom predicates, not only the <(node) and >(node) ones supported currently.

• step 1

Run the current set of tests but on a grid. For instance, we have an entanglement generator between all nearest neighbors on a square grid, but only a chain through the diagonal is running swaps. In such a case, we will need a predicates that are not simply <(node) and >(node) but rather 'the other node is above and to the left of node' and 'the other node is below and to the right of node'.

• step 2

Good animated examples added to the documentation.

The project is claimed by @coderight1 until Aug 12th 2024.

Project: "More thorough benchmarks" [$200]

We have a small benchmark suite already implemented, which is executed as part of our CI runs. It is defined in the benchmark folder and reported for each pull request. We would like to expand this benchmark suite to include many more facets of this library. E.g. basic register operations using a variety of backends; queries and tags and locks on registers and channels; time to import; time to run examples. The new benchmarks should be legible, easy to follow, and organized by topic. Most of them should be microbenchmarks testing only one concept, but a few holistic benchmarks would make sense as well.

Required skills: Generic Julia skills.

Reviewer: Stefan Krastanov

Duration: 1 month

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

I was trying to install QuantumSavory in a Pluto notebook and noticed that the current release v0.3.0 won't precompile because its missing the consistent_representation method defined here which is causing this line in src/precompile.jl to error

ERROR: LoadError: MethodError: no method matching consistent_representation(::Vector{QuantumSavory.Register}, ::Vector{Int64}, ::QuantumSymbolics.XBasisState)

Closest candidates are:
  consistent_representation(::Any, ::Any)
   @ QuantumSymbolics C:\Users\Abhishek Bhatt\.julia\packages\QuantumSymbolics\QFyHe\src\QSymbolicsBase\express.jl:35

Stacktrace:
  [1] initialize!(r::Vector{QuantumSavory.Register}, i::Vector{Int64}, state::QuantumSymbolics.XBasisState; time::Float64)
    @ QuantumSavory C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\baseops\initialize.jl:37
  [2] initialize!(reg::QuantumSavory.Register, i::Int64, state::QuantumSymbolics.XBasisState; time::Float64)
    @ QuantumSavory C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\baseops\initialize.jl:35
  [3] initialize!(r::QuantumSavory.RegRef, state::QuantumSymbolics.XBasisState; time::Float64)
    @ QuantumSavory C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\baseops\initialize.jl:36
  [4] macro expansion
    @ C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\precompile.jl:22 [inlined]
  [5] macro expansion
    @ C:\Users\Abhishek Bhatt\.julia\packages\PrecompileTools\kmH5L\src\workloads.jl:78 [inlined]
  [6] macro expansion
    @ C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\precompile.jl:6 [inlined]
  [7] top-level scope
    @ C:\Users\Abhishek Bhatt\.julia\packages\PrecompileTools\kmH5L\src\workloads.jl:140
  [8] include(mod::Module, _path::String)
    @ Base .\Base.jl:457
  [9] include(x::String)
    @ QuantumSavory C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\QuantumSavory.jl:1
 [10] top-level scope
    @ C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\QuantumSavory.jl:337
 [11] include
    @ .\Base.jl:457 [inlined]
 [12] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::String)
    @ Base .\loading.jl:2049
 [13] top-level scope
    @ stdin:3
in expression starting at C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\precompile.jl:3
in expression starting at C:\Users\Abhishek Bhatt\.julia\dev\QuantumSavory\src\QuantumSavory.jl:1
in expression starting at stdin:3

• netsquid
• quisp
• quentsim
• simulaqron
• requsim

We generate a lot of info-level logs during tests. Disable those or direct them to a file. Only print warnings and above

#94 has set the groundwork for this

We need to think about what to do when the state is entangled with other locations

Now that #81 is merged, we need to start trying to break it -- it is still rather fragile.

• Step 0:

If we are going to have a lot of rounds of entanglement, we need some way to "consume" the final entangled pairs so that we do not run out of slots. A good way to do this would be to have EntanglementConsumer protocol which attempts to consume a bell pair at a fixed rate.

It can look something like

EntanglementConsumer(nodeA::Int, nodeB::Int, log::Vector{Any}, period::Float64)

When started, this protocol will query both nodeA and nodeB to check whether they have shared entangled pairs, it will then measure their ZZ and XX observables and it will store a log of (time, observables). After a successful query the slots of the pair get freed up. When the queries fail it will just store a (time, nothing). It will perform the query every period units of time.

• Step 1:

First thing to do is to run tests similar to test_entanglement_tracker but with EntanglerProt(...rounds>1). This will cause issues because the old "entanglement history" tags might mess up update messages coming from newer swaps. Maybe a proper ordering of the query lookup (FILO vs FIFO) is enough and we do not need to worry. In either case though, we should have much more detailed tests for such situations. The test can be simply verifying that the log from EntanglementConsumer has observables that are always equal to 1.

• Step 2:

Now we want to run with multiple EntanglerProt per neighbors, not simply one EntanglerProt(...rounds>2)

• Step 3:

Start worrying about "memory leaks". We need to figure out how to deal with very old history tags -- at some point they should be deleted. This will need figuring out...

• need for uuid:

It is possible that we will need to add uuids to the entanglement tags to solve some of these issues.

• Documentation:

And there will be a lot of documentation work to figure out here. This will be a multi-week task of its own.

we have not been testing them for a while because of timeouts on github CI. Should move to buildkite soon @Abhishek-1Bhatt

With the new release of ResumbaleFunctions(v0.6.7) in JuliaDynamics/ResumableFunctions.jl#81 and the new Julia v1.10.0 release, we have some breakage:

using QuantumSavory
using QuantumSavory.ProtocolZoo: EntanglementTracker

using ConcurrentSim
using ResumableFunctions
using Graphs

net = RegisterNet([Register(3) for i in 1:3])
sim = get_time_tracker(net)

for v in vertices(net)
    tracker = EntanglementTracker(sim, net, v)
    @process tracker()
end

julia> run(sim, 100)

ERROR: MethodError: Cannot `convert` an object of type Nothing to an object of type String

Closest candidates are:
  convert(::Type{String}, ::Base.JuliaSyntax.Kind)
   @ Base C:\workdir\base\JuliaSyntax\src\kinds.jl:975
  convert(::Type{String}, ::String)
   @ Base essentials.jl:321
  convert(::Type{T}, ::T) where T<:AbstractString
   @ Base strings\basic.jl:231
  ...

Stacktrace:
  [1] setproperty!(x::QuantumSavory.ProtocolZoo.var"##prot::EntanglementTracker_FSMI#258", f::Symbol, v::Nothing)
    @ Base .\Base.jl:40
  [2] macro expansion
    @ C:\Users\abhishek_bhatt\.julia\dev\ResumableFunctions\src\transforms.jl:254 [inlined]
  [3] macro expansion
    @ C:\Users\abhishek_bhatt\.julia\dev\QuantumSavory\src\ProtocolZoo\ProtocolZoo.jl:82 [inlined]
  [4] (::QuantumSavory.ProtocolZoo.var"##prot::EntanglementTracker_FSMI#258")(_arg::Nothing)
    @ QuantumSavory.ProtocolZoo C:\Users\abhishek_bhatt\.julia\dev\ResumableFunctions\src\macro.jl:248
  [5] execute(ev::ConcurrentSim.Initialize, proc::Process)
    @ ConcurrentSim C:\Users\abhishek_bhatt\.julia\dev\ConcurrentSim\src\processes.jl:32
  [6] (::ConcurrentSim.var"#1#2"{typeof(ConcurrentSim.execute), ConcurrentSim.Initialize, Tuple{Process}})()
    @ ConcurrentSim C:\Users\abhishek_bhatt\.julia\dev\ConcurrentSim\src\base.jl:51
  [7] step(sim::Simulation)
    @ ConcurrentSim C:\Users\abhishek_bhatt\.julia\dev\ConcurrentSim\src\simulations.jl:39
  [8] run(env::Simulation, until::ConcurrentSim.Timeout)
    @ ConcurrentSim C:\Users\abhishek_bhatt\.julia\dev\ConcurrentSim\src\base.jl:91
  [9] run(env::Simulation, until::Int64)
    @ ConcurrentSim C:\Users\abhishek_bhatt\.julia\dev\ConcurrentSim\src\events.jl:29
 [10] top-level scope
    @ c:\Users\abhishek_bhatt\.julia\dev\buffer2.jl:23

The compat bound for RF has been lowered in #87 for now.

Applying CNOT_2->1 to states |01> and |10> returns |01> and |11> respectively. It returns correct answer for other 2 qubit combinations though and works correctly when doing CNOT_1->2.

using QuantumSavory

ra = Register(1)
rb = Register(1)

initialize!((rb[1], ra[1]), L0⊗L1) ## |01⟩
ra.staterefs[1].state[]

apply!((ra[1], rb[1]), CNOT) ## correct: |11⟩ gives: |01⟩ (no change)
ra.staterefs[1].state[]

Shows up in #34

Following #92 further documentation should be added for demonstrating query capabilities to the user.

Project: Entanglement tracker protocol with UUIDs assigned to each Bell pair [$1600]

An important feature for any simulation involving non-trivial networking is tracking entanglement swaps. Consider a chain of repeaters between nodes A and B. Only "link-level" raw entanglement can be generated, entangling only nearest neighbors. Entanglement swaps are necessary at each repeater in order to take the many "link-level" pairs and turn them into one pair between A and B. However, whenever a swap happens, classical messages need to be sent through the network, alerting the other end of a pair that has undergone a swap that they are now entangled to a completely different node. One such set of protocols is currently implemented in EntanglementTracker (and EntanglerProt and SwapperProt), using tags like EntanglementUpdate and EntanglementHistory. This protocol is very "stateful" and requires detailed history to be kept.

This bounty is about implementing an alternative protocol, one in which each pair is assigned a UUID and entanglement tracking and updates use these IDs instead of trying to keep as detailed of a history.

Detailed documentation, visualizations, examples, and comparisons to the already available protocols also would need to be provided as part of this bounty.

Required skills: Understanding of entanglement swapping, and concurrent programming with the ConcurrentSim.jl and ResumableFunctions.jl libraries.

Reviewer: Stefan Krastanov

Duration: 2 months but can easily be extended

Publication: In the next 2 years we plan to release a paper in a selective journal about this software. Contributing to this issue would deserve a co-authorship status on such a paper (if the contributor so desires)

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

apply! has now moved to QuantumInterface, and is needed by QuantumSymbolics and QuantumSavory. Make sure you are using consistent argument order for it. In particular, most places now use apply!(state, indices, operation).

These need to be deprecated and reordered:

[5] apply!(r::QuantumClifford.Register, op, args...; kwargs...) @ QuantumClifford ~/Documents/ScratchSpace/quantumjulia/QuantumClifford.jl/src/classical_register.jl:35
[6] apply!(state::MixedDestabilizer, gseq::QuantumSavory.QCGateSequence, indices) @ QuantumSavory ~/Documents/ScratchSpace/quantumjulia/QuantumSavory.jl/src/backends/clifford/should_upstream.jl:6
[7] apply!(stab::QuantumClifford.AbstractStabilizer, op::QuantumClifford.AbstractCliffordOperator, indices; phases) @ QuantumClifford ~/Documents/ScratchSpace/quantumjulia/QuantumClifford.jl/src/QuantumClifford.jl:1139
[8] apply!(state::MixedDestabilizer, op::Type{<:AbstractSymbolicOperator}, indices) @ QuantumSavory ~/Documents/ScratchSpace/quantumjulia/QuantumSavory.jl/src/backends/clifford/should_upstream.jl:1

@Barosandu , could you add references in the docstrings for these circuits. You need to add them to the bibtex file and then add @cite references, e.g. the way it is done here: https://github.com/QuantumSavory/QuantumClifford.jl/blob/cb1b5913c959db8855f5f29e4df9d4a00e380871/src/enumeration.jl#L84

• Fix the occurrence of deadlocks, when running the control protocols for infinite rounds
• Entanglement tracker needs better interface for accessing the logs
• Webgl demo for the simulation

(moved here from: #107 (comment))

Currently we visualize states stored in registers as black diamonds. We should also have a way to denote states that are currently traveling through a channel, especially if they are entangled with something. Maybe we can show them as traveling arrows with location interpolated between two nodes.

#94 has set the groundwork for this

#94 has set the groundwork for this

#94 has set the groundwork for this

If a register slot is locked, show a small lock icon to the side

Currently we implicitly have FIFO order.

This should be a parameter to query and querydelete! (renamed from querypop!)

We can use types in order to have specialization:

struct FILO end
struct FIFO end

@Barosandu , could you change the parameterization of the 3to1 circuit so the user can change which error is being purified at each step (e.g. detecttwice=Z can be leaveout = (Y,X), (X,Y), (X,X), or (Y,Y)).

Probably two leaveout parameters is easiest to set up.