Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generation of Random Circuits with Pre-Defined Inter-Qubit Connectivity #12364

Open
sbrandhsn opened this issue May 7, 2024 · 3 comments
Open
Labels
type: feature request New feature or request unitaryhack-bounty Issues/PR participating (now or in the past) in the UnitaryHack event see https://unitaryhack.dev/

Comments

@sbrandhsn
Copy link
Contributor

sbrandhsn commented May 7, 2024

What should we add?

The generation of random circuits should be extended by the ability to specify a circuit connectivity or interaction graph $G$ that the random graph should should adhere to. The interaction graph $G$ of a circuit is determined by the set of two-qubit gate interactions $g_{1}=(v_{1}, u_{1}), ..., g_{n}=\{v_{n},u_{n}\}$ with qubits $V=\{v_{i}\}$ in the circuit such that $G=(V, E)$ where $E=\{g_{i}\}$. You can generate the interaction graph of a circuit using vf2_utils.build_interaction_graph. For instance, let $G=(V, E)$ be a line graph over $n$ qubits such that $E=\{\{v_{i}, v_{i+1}\} | $ for $i=0...n-2$ $\}$, then each two-qubit gate in the random circuit may only interact on neighboring qubits $v_{i}, v_{i+1}$.

To realize this behavior, please create a new function random_circuit_from_graph to https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/random/utils.py with the parameters
interaction_graph, max_operands=2, measure=False, conditional=False, reset=False, seed=None that represents the graph $G$ as above. The number of vertices in interaction_graph define the number of qubits in the circuit to be generated and the depth parameter specifies how often each qubit-pair must at least be used in a two-qubit gate before the circuit is returned. The remaining parameters should follow the definition of random_circuit in https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/random/utils.py#L23.

Optional edge weights in interaction_graph must be positive and should be normalized to sum up to 1.0. The now normalized edge weights represent the probability with which each qubit-pair interaction is inserted into a layer. An uniform edge weight would indicate that each two-qubit gate between the pairs specified in interaction_graph are equally likely to get inserted into a layer of the generated random circuit.

Please also add tests to validate your changes and add a release note according to https://github.com/Qiskit/qiskit/blob/main/CONTRIBUTING.md

Note that this is a subtask of #11718 and connected to #12059. :-)

@sbrandhsn sbrandhsn added the type: feature request New feature or request label May 7, 2024
@jakelishman
Copy link
Member

This sounds highly specific, so is it worth making a different function for it? The behaviour sounds really quite different to the existing random_circuit, but random_circuit_with _graph might give more room for expansion?

@sbrandhsn
Copy link
Contributor Author

Sounds good to me, thanks for that comment! I was a bit worried because of code duplication but I think it makes sense to have a separate function - I edited the issue to reflect that. :-)

@1ucian0 1ucian0 added the unitaryhack-bounty Issues/PR participating (now or in the past) in the UnitaryHack event see https://unitaryhack.dev/ label May 8, 2024
@MozammilQ
Copy link
Contributor

Does one need to do PR first and then the issue gets assigned or the issue gets assigned and then one does the PR?
is the issue assignable only between 29th May - 12th June or can it be assigned earlier?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request New feature or request unitaryhack-bounty Issues/PR participating (now or in the past) in the UnitaryHack event see https://unitaryhack.dev/
Projects
None yet
Development

No branches or pull requests

4 participants