lazyoracle
commented
2 years ago 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.
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 https://github.com/q-optimize/c3/issues/172#issuecomment-1005166559_