-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add Clifford simulator implementation #253
Comments
Hi @rmshaffer made a PR to clear the issue |
Hi @speller26 and @rmshaffer I Have to give up on this issue unfortunately |
Hi, |
Either is fine; a wrapper is much more doable, but we're not ruling out a high-performance custom implementation, which would be incredibly impressive! |
Hello, |
Not all gates have to be supported; as well, the simulator implementation does not need to decompose gates. So you are correct, it is enough to raise an exception if a gate is not explicitly supported. |
My understanding of the program flow is that an OpenQASMSimulator.run call creates a ProgramContext, calls OpenQASMSimulator.parse_program to create an interpreter which then modifies the ProgramContext by parsing the QASM instructions into whatever representation the ProgramContext specifies (typically braket, but in my case stim), then takes the circuit property of this modified ProgramContext and extracts information about the circuit such as the qubits used, the qubits that need to be measured, and the actual instructions in the circuit, and sends all of this to a Simulation object to evolve the state and get results, which are then returned in the form of a GateModelTaskResult object. Rather than making a CliffordSimulation class, I believe the best course of action is to create a braket.Circuit object and have CliffordSimulator.run build an appropriate stim.Circuit according to the instructions in the braket.Circuit class, so stim.Circuit would then occupy the same role that Simulation does. The issue with this approach is that braket.Circuit objects store GateOperations, which stim instructions clearly are not. I would like to write my own CliffordCircuit class to store stim operations, but the lack of an abstract Circuit class makes it a bit more difficult to tell what exactly the desired interface is (for example, should circuit.basis_rotation_instructions be implemented?). What exactly would such a CliffordCircuit class need to implement? Or could I just write it as a class exclusively used by CliffordProgramContexts which only stores basic data about the circuit and the list of instructions? I also have some questions about some of the work done in the BaseLocalSimulator.run_openqasm method:
|
I'd like to work on this issue, feel free to assign it to me. |
Describe the feature you'd like
Stabilizer circuits can be classically simulated efficiently, and are very useful in quantum information research, for example in quantum error correction. To support these use cases, it would be good to have a Clifford simulator target for the local simulator:
This should be done by implementing the OpenQASMSimulator interface to translated OpenQASM into simulator instructions.
How would this feature be used? Please describe.
Fast simulation of large stabilizer circuits, for example with thousands of qubits and gates.
The text was updated successfully, but these errors were encountered: