Closed ba2tro closed 1 day ago
Attention: Patch coverage is 80.39216%
with 20 lines
in your changes missing coverage. Please review.
Project coverage is 72.92%. Comparing base (
6e99352
) to head (a56e783
). Report is 1 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Now we have a DecoherenceProtocol
at each node that throws away qubits past their retention while tagging the slot with a new EntanglementDelete
tag. The EntanglementDelete
tag is also sent as a message to the node which was entangled with the deleted qubit. This logic to handle the different cases arising from this message is added to the code in EntanglementTracker
The two example files have a lot in common. Could you make a setup.jl
file that contains everything that is common so it is easier to see the difference?
There is a conflict with queries.jl
now. I think the only change you had actually made to that file is to add iscoherent
. It probably will be easiest to just checkout the master version of the file and manually add iscoherent
instead of going through each merge difference (I think that had already led to some weirdness in the previous merge conflict resolution).
I set up a CHANGELOG file, so that it is easier to keep track of updates and breaks. We can follow the same style as in QuantumClifford.jl
Is this ready for review? There seems to be a couple of unaddressed comments still. I will convert it to a draft to make it easier for me to track what I am supposed to review.
Is there a separate commit for the renaming of the swapper protocol and for the changes in the swapper protocol? It is very difficult to figure out what is happening because the renaming and the changes are rendered together. Could you talk through what the changes to that protocol are (besides renaming)? Are any of the changes breaking (which would require double checking manually that the examples still work)?
findswappablequbits has a bunch of new arguments that are not documented and I am not sure what they mean
This is great and the visualizations look awesome! I made some small refactoring changes (and one big one, after noticing how close the two Swapper protocols are). I added a bunch of TODOs that I will turn into issues.
Please check the commits I pushed (I tried to have them separate by topic so they are easy to follow) and let me know if something is amiss.
An appropriate priority at this point would be to create a comparison study of these two protocols (not just two separate demos, but a scientific study that spans various parameters)
Looking at the buildkite failure, this seems to still suffer from the race condition in the swapper/tracker. Could you fix that here as well today (Wed), so that we can merge it?
The documentation seems to be failing to build still.
request a review when these are fixed -- I should be able to see it on my queue
@Abhishek-1Bhatt , just a bump on the documentation issues
https://github.com/QuantumSavory/QuantumSavory.jl/actions/runs/10334602640/job/28608236059?pr=120#step:6:1186 Looks like this is creating a persistent task during the precompilation causing the gh action CIs to fail the aqua tests.
I get another similar warning locally:
WARNING: Method definition traceout!(QuantumOpticsBase.Operator{BL, BR, T} where T where BR where BL, Any) in module QuantumOpticsBase at /home/ba2tripleO/.julia/packages/QuantumOpticsBase/QN1iB/src/operators_dense.jl:31 overwritten in module QuantumSavory at /home/ba2tripleO/.julia/dev/QuantumSavory/src/backends/quantumoptics/quantumoptics.jl:21.
ERROR: Method overwriting is not permitted during Module precompilation. Use `__precompile__(false)` to opt-out of precompilation.
I see there's work going on in qobase, the docs are building now(other than the random xvfb errors that happen now and then).There was an @ref
that doesn't have a doctrine in qsymbolics
you are getting these warnings because https://github.com/QuantumSavory/QuantumSavory.jl/pull/143 is in progress. Do not worry about them.
@Krastanov this is ready to be merged
Woohoo! Thanks for taking care of this and shepherding it through the review process. I made a few changes, some related to minor stylistic documentation personal preferences, some related to the stability of the tests that were failing. Please check them out to make sure I did not miss anything.
I made a related issue #147 for a few minor things that would be nice to fix, but were not blocking.
Thanks a lot for pushing it through!
Based on #114 and continued from #107
Besides the documentation work from #107 , the following changes are introduced to add decoherence to the protocols
guid
associated with slot is stored in a vector field in Register, earlier there was no way to access a slot's tag information just from the slot, this helps to implement theiscoherent
function which just takes a slot and checks whether its coherent or notretention_times
which allows the user to provide individual retention time for each slot which is set to 5.0 time units by defaultiscoherent
function which takes a slot and returns whether its coherent or not. It also takes abuffer_time
parameter, so that a swapper can choose slots that would be coherent for, say 2.0 units of time, and the messages passing is completed before the slot gets decoherentEntanglerProt
and more specificallyfindfreeslot
has been modified to return already assigned slots that have decohered after ituntag!
s andtraceout
s them, this way we don't need a separate protocol to free the decoherent slots and make more mess. This also removes the need for themargin
parameter inEntanglerProt
that we were passing tofindfreeslot
and greatly simplifies the function bodyThis deals with the deadlocks and the plots from the grid example look pretty cool:
https://github.com/QuantumSavory/QuantumSavory.jl/assets/46929125/3fdd66a8-667f-488b-9781-cb6f5b416d2b