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

QPU structure interoperability between qiskit and c3 #173

Open
lazyoracle opened this issue Jan 6, 2022 · 1 comment
Open

QPU structure interoperability between qiskit and c3 #173

lazyoracle opened this issue Jan 6, 2022 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@lazyoracle
Copy link
Member

It would be nice if there is a way of mapping / distilling the QPU structure defined in C3 to a QISKIT QPU structure, so that gate-only circuits (i.e. no pulse gates) can be quickly checked using the QISKIT Aer native simulators
https://qiskit.org/documentation/tutorials/simulators/1_aer_provider.html.

Optional extra bonus points if we can bootstrap a C3 QPU definition from a QISKIT QPU definition and a specification of the type of qubits and couplers.


Originally posted by @shaimach in #172 (comment)_

@lazyoracle lazyoracle self-assigned this Jan 6, 2022
@lazyoracle lazyoracle added the enhancement New feature or request label Jan 6, 2022
@lazyoracle lazyoracle added this to the 1.4.1 milestone Jan 6, 2022
@lazyoracle
Copy link
Member Author

Notes from @shaimach from the QC stack repos in Jülich

Created by: shaimach

One of the goals of C³ it to create a digital twin simulation for the quantum devices.

We should start along the path by having a simulation twin for each QPU we connect via the QISKIT interface.

Maybe the same Provider will have both the physical device and its digital twin. Maybe it'll be different Providers - whatever is simpler initially.

This will allow users to run the same experiment first on the simulation and then, assuming everything works well, a simple one-line change will make it work on the physical device.

Initially, the digital twin can be fairly inaccurate - just have the right number of qubits and connectivity. But slowly we'll figure out how to fully characterize the QPU and update the twin accordingly.

One point where they will differ is the output supported - it is ok if the twin only does summary statistics (i.e. get_counts) and the number of shots is not bounded (so you can specify 1e99 shots and get the right ratios). There may be other differences.

The critical point is that I can first run my experiment on the twin, and then on the real device with only super-minor changes to my program.

Nice to have: Container magic so that if the job queue for the simulator is getting long, new copies of the simulator will be automagically created to reduce job waiting times.

@lazyoracle lazyoracle removed this from the 1.5 milestone Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant