Replies: 2 comments 1 reply
-
A few points:
Suggested Roadmap:
|
Beta Was this translation helpful? Give feedback.
1 reply
-
@urig this is a discussion on QPU-DB and its future |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What is a Parameter DB and why do I want one?
One of the main challenges in running complex multi-node experiments on a graph is dealing with system parameters.
For example, you may need to keep track of resonant frequencies and DC bias values that are different for different nodes.
Parameters therefore need a central location where they are stored. This store needs to be able to track versions of parameter sets, similar to a git repository. This is both so you can go back to previous known states of the system and for the values of the parameters to be contextual. By this, we mean different nodes in the graph need different parameter values by design. Sometimes you want to set a qubit to be off resonant when you are tuning a couple for example. This can be resolved with an appropriate DB design.
We believe this is a central concept and will therefore build and incorporate a parameter DB into Entropy.
Doesn't the QPU-DB already do this?
We've tried to solve the parameter management problem by building the QPU-DB .
The QPU-DB, alongside the QuaCalNode which is introduced in the same repository, are meant to solve two problems:
The design decision made in building the QuaCalNode was the the QUA config is built incrementally. A root node is used to prepare the base configuration and that configuration is then explicitly passed from one node to the other.
Each QuaCalNode updates the configuration, runs and experiment (optionally) and passes the resulting configuration down the graph. These specialized nodes were also built with functionality to merge configurations passed down the line. This is crucial as multiple nodes can feed into a single node down the line.
So what do you want to build now?
It seems passing the config from node to node explicitly is not convenient in many cases.
As an alternative we plan to have a function to generate the qua config from the parameters stored in the DB.
This addresses a specific QUA issue. However, it is noted that there is a more general problem that can be tackled here. A configuration may also involve additional, external devices. For example, a configuration for an external mixer or LO source which may also depend on parameters in the parameter DB. We also mean to address this issue.
How is this a discussion then?
This post is experimental. We want to build the parameterDB and give nodes the ability to use it as an Entropy resource.
We will first build a parameter DB which runs in memory (no persistence) and can be used by nodes. This will also include the qua config generator function.
After that we will add a persistence layer.
We will then add a caching mechanism which allows speeding up the config creation process.
Then we'll see.
What do you think of this structure? @talshani
Beta Was this translation helpful? Give feedback.
All reactions