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

Add Clifford simulator implementation #253

Open
speller26 opened this issue May 9, 2024 · 8 comments
Open

Add Clifford simulator implementation #253

speller26 opened this issue May 9, 2024 · 8 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@speller26
Copy link
Member

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:

sim = LocalSimulator("braket.clifford")

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.

@speller26 speller26 added the enhancement New feature or request label May 9, 2024
@speller26 speller26 changed the title Implement a Clifford simulator Add Clifford simulator implementation May 9, 2024
@rmshaffer rmshaffer added the good first issue Good for newcomers label May 14, 2024
@AbdullahKazi500 AbdullahKazi500 mentioned this issue May 31, 2024
5 tasks
@AbdullahKazi500
Copy link

Hi @rmshaffer made a PR to clear the issue

@AbdullahKazi500
Copy link

Hi @speller26 and @rmshaffer I Have to give up on this issue unfortunately
it was great working on this but I will be active for contributions later on

@golanor
Copy link

golanor commented Jun 4, 2024

Hi,
Do you expect a full simulator, or a wrapper over an existing simulator, such as stim?

@speller26
Copy link
Member Author

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!

@dobbse42
Copy link

Hello,
Am I correct in understanding that OpenQASMSimulator implementations do not support modifying existing circuits? Additionally, AbstractProgramContexts require appropriate handling of custom unitaries. While this is convenient for a general simulator, a clifford simulator would have to verify that the provided unitary can be implemented by only clifford gates and also find a corresponding clifford decomposition. This seems beyond the scope of this issue, so would it be acceptable to simply raise an exception if that function is ever called?

@speller26
Copy link
Member Author

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.

@dobbse42
Copy link

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:

  1. Much of run_openqasm seems to be focused on validating properties extracted from circuit object returned by the ProgramContext. What criteria exactly are these methods validating against?
  2. I am unsure as to the purpose of the qubit_map and all the associated lines such as mapping the measured qubits.
  3. What exactly are the results objects? As far as I can tell the Results referenced in all the simulator code comes from jaqcd (looking here), but this implies that any results taken from a stim circuit would need to be mapped back to one of these objects, and I am unsure exactly where we would want that to take place (should it be done in CliffordProgramContext.add_result? Or in CliffordCircuit.add_result?).

@navaro1
Copy link

navaro1 commented Oct 19, 2024

I'd like to work on this issue, feel free to assign it to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

6 participants