search

QuantumSavory / QuantumSavory.jl

A full stack simulator of quantum hardware, from the low-level analog physics to high-level network dynamics. Includes discrete event simulator, symbolic representation for quantum object, and works with many backend simulators.
https://quantumsavory.github.io/QuantumSavory.jl/
MIT License
30 stars 11 forks source link

Waiting on register events [$800] #133

Open Krastanov opened 2 months ago

Krastanov commented 2 months ago
Bug bounty logistic details (click to expand) To claim exclusive time to work on this bounty either post a comment here or message [skrastanov@umass.edu](mailto:skrastanov@umass.edu) with: - your name - github username - **(optional)** a brief list of previous pertinent projects you have engaged in Currently the project is claimed by `no one` until `...`. If you want to, you can work on this project without making a claim, however claims are encouraged to give you and other contributors peace of mind. Whoever has made a claim takes precedence when solutions are considered. You can always propose your own funded project, if you would like to contribute something of value that is not yet covered by an official bounty.

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.

hanakl commented 2 weeks ago

I've talked to @Krastanov and will be working on this!