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.

@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

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.

@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.

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.

#94 has set the groundwork for this

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

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

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

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.

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.

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

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

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

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

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!

#94 has set the groundwork for this

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

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.

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.

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

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

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

• netsquid
• quisp
• quentsim
• simulaqron
• requsim

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)

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

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

#94 has set the groundwork for this

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

@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.

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

• 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))