Add Simulation method based on Stabilizer Rank Decompositions #51

padraic-padraic · 2019-02-08T19:08:38Z

Summary

Add a simulator based on decompositions into stabilizer states, as described in arXiv:1808.00128
Includes support for simulating Clifford + T/CCZ/Toff/u1 gate circuits
Falls back to a stabilizer simulator based on the 'CH' representation for Clifford circuits

Details and comments

Resolves #47.

This is a work in progress to add a simulator for circuits with a small number of non-Clifford gates, but with support for up to 63 qubits.

Currently, it exists as a standalone c++ simulator and controller. To integrate it with the QASMController we still need

A heuristic for switching to the CH backend when method == 'automatic'.
To update the tests for the 0.1.1 release
A way to check the memory requirements in qiskit.providers.aer.QasmSimulator.validate and qiskit.providers.aer.CHSimulator.validate.
Documentation updates
CHANGELOG updates

… state

TODO: Add flag to enable NormEstimation TODO: Add UserGuide for the CH Simulator TODO: Pauli/Clifford noise support

TODO: Update tests, heuristic for switching to ch when using the qasm simulator in 'automatic' mode.

CLAassistant · 2019-02-08T19:08:45Z

All committers have signed the CLA.

Defined for the CH simulator only; could consider making this a virtual method of the base controller class?

atilag · 2019-02-11T16:35:15Z

Thanks for the contribution @padraic-padraic , this is great!

Remember to add some tests to your TODO list ;)
I'll start reviewing soon so we can start fixing minor things while you are still working in the changes

padraic-padraic · 2019-02-12T13:44:18Z

Thanks for handling the review!

The tests have been added and updated in my most recent commit; one caveat with this simulation method at the is its performance on strongly peaked output distributions, which is why the last build failed on the Grover case. Bumping up the number of shots leads to a reproducable pass on my end, which I'll push once I've added the QasmController integration.

chriseclectic

This is great @padraic-padraic, I haven't looked through the code in detail but my main comment from a functional point of view would be to remove the standalone backend class and have it accessed through the QasmSimulator by setting the simulation method.

I guess we would need to do some profiling to find a good automatic criterion, but I would say you want to check 2 conditions:

The noise model is only Clifford + reset operations (like for the stabiliser method), so we don't accidentally add too many expensive t-gates into the circuit through noise sampling.
The second condition I am imagining is a function of the number of t/u1 gates and qubit number, but I'm sure you or Sergey have a better ball-park idea for what this could be.

chriseclectic · 2019-02-13T04:53:45Z

qiskit/providers/aer/aerprovider.py

@@ -26,7 +27,8 @@ def __init__(self, *args, **kwargs):
        # Populate the list of Aer simulator providers.
        self._backends = [QasmSimulator(provider=self),
                          StatevectorSimulator(provider=self),
-                          UnitarySimulator(provider=self)]
+                          UnitarySimulator(provider=self),
+                          CHSimulator(provider=self)]


@padraic-padraic are you ok with removing the seperate backend and only having it accessed through QasmSimulator using backend_options = {"method": "ch"}?

We want to keep the number of backends in the provider down and have them based on their functional output, so all the backends that are designed to mimic a circuit experiment will come under the QasmSimulator

Yeah, I think that would work. Most of the CHController is a shadow of the QasmController API anyway.

The one addition I made to the API is the required memory validation. We could add something like this to the QasmController? Or else I port it to Python, but either way we'd need to update the _validate method of QasmSimulator to account for the different footprints of the CH/Statevector methods.

Adding the memory validation to the QasmController / Base Controller sounds good. We've been meaning to do something like this for awhile, since we should really be doing it for the statevector simulator as well (stabilizer too though in that case its memory footprint is comparatively tiny).

Currently the memory is checked in python before sending the qobj so it can fail-fast, but if we handle it correctly in the C++ we could remove that part from the python backend (or just do a very basic check there).

For the moment I'll leave the simple check in Python, and set it to auto-switch to ch in the event that the number of qubits is too much for the statevector method (as long as it's not too high for the ch method). I guess the thing to do would be to make use of the required_memory_mb method of state as part of an initialisation step in QasmController?

src/base/state.hpp

padraic-padraic · 2019-02-21T17:03:27Z

One question I have is for calling compile with the QasmSimulator class; as it stands, QasmSimulator doesn't use the configuration kwarg to the AerBackend constructor, instead just passing a BackendConfiguration instance initialsied with QasmSimulator.DEFAULT_CONFIGURATION, which has properties like n_qubits and basis_gates configured for the statevector simulator. Is that going to potentially cause problems when it comes to compiling to a Qobj etc? Because ch currently doesn't implement u2 or u3 gates.

This also has relevance for when we auto-switch to ch, so I'll add a quick check to QasmSimulator._validate to catch any illegal instructions before auto-selecting ch.

…imulator

chriseclectic · 2019-02-21T19:21:25Z

@padraic-padraic yes we may need to rethink that on the Terra side, but for now the default basis gates includes the most general basis gates for the simulator (ie the statevector method). This means by default if it has gates like h, x, y etc they won't be converted to u2, u3 gates, however if a circuit already has u2 or u3 gates in it then it can't be run on the CH or stabilizer simulator. We add multiple default configuration dicts for each of the simulation methods to make it more explicit what each method supports. Any ideas for this @atilag @ajavadia?

The general gateset shouldn't be a problem for the automatic method as it will check if gates in the circuit are supported on the different methods and choose one. If a user tried to force running on the stabilizer or CH simulator on a circuit with u3 gates (eg "method": "ch") the simulator (or python validation before simulation) will raise an exception that the circuit has unsupported gates. You can see how this behave with the current stabilizer simulator.

padraic-padraic · 2019-02-25T14:31:23Z

Just a note on this; I've got most of the benchmarks done to implement a heuristic swticher for CH/QASM, and I've added memory validation in the QasmController as part of validate_state (which takes into account experiment parallelisation. To avoid cross-platofrm headaches, I used psutil to pass available memory in as part of the Qobj config). I also fixed a bug in the standalone simulator where QasmController::set_config was never being called due to the qobj being run through BaseController::execute.

However, I've been running into some odd intermittent crashes when calling the CH simulator from within Python. I'm just working on debugging those, hopefully should have a sense of what's going on by tomorrow!

padraic-padraic · 2019-02-28T16:41:47Z

Hi both,

This is pretty much done from my end! Here's what's in the latest change

Memory validation: Base::Controller::validate_required_memory will, if the QObj has available_memory in its config, check the requirements of the circuit. This is a separate method from validate_state as it requires a member variable. If validate_state weren't static (which could be the case, as currently it's only called from inside run_circuit_helper), then this function could be folded in to that.
The AerBackend will use qiskit._util.local_hardware_info to pass the available_memory to the QasmController if it's not specified by the user.
The QasmController will automatically switch to the CH method only if the circuit is too large to tackle with the statevector method. I think this makes most sense. As CH is an approximate simulation method, and also requires some configuration in the case of strongly peaked output distributions, I think in most cases its best that using it is a conscious choice on the part of the user.

atilag

Great Job @padraic-padraic,
I haven't finished the review, but I left some comments regarding coding style.
I'll follow the review later.

atilag · 2019-03-05T09:52:03Z

qiskit/providers/aer/backends/aerbackend.py

@@ -114,6 +115,9 @@ def _format_qobj_str(self, qobj, backend_options, noise_model):
        if backend_options is not None:
            for key, val in backend_options.items():
                config[key] = val
+        if not "available_memory" in config:


As we may want to offer the possibility to the user to specify the available_memory through a config parameter, I'd rather calculate the real available memory in the simulator side if the user doesn't set this parameter.

atilag · 2019-03-05T09:54:27Z

qiskit/providers/aer/backends/qasm_simulator.py

@@ -152,6 +185,9 @@ def _validate(self, qobj, backend_options, noise_model):
                               'result data will not contain counts.', name)
            # Check if Clifford circuit or if measure opts missing
            no_measure = True
+            ch_supported = False


What about:

ch_supported = True if method == "ch" or method == "automatic" else False

... using the same structure than the following expression.

I went for

ch_supported = method in ['ch', 'automatic']

to keep the line short!

atilag · 2019-03-05T10:01:39Z

qiskit/providers/aer/backends/qasm_simulator.py

+                                                   self.name(), system_memory)
+                    if method != "automatic":
+                        raise AerError(err_string + '.')
+                    else:


There's no need for this else here... raising will terminate the function.
We can decrease the indentation then

atilag · 2019-03-05T10:02:55Z

qiskit/providers/aer/backends/qasm_simulator.py

+                            raise AerError(err_string + ', and has too many ' +
+                                           'qubits to fall back to the ' + 
+                                           'CH simulator.')
+                        elif not ch_supported:


No need for elif, a simple if will be enough as the above raise will terminate the function

atilag · 2019-03-05T10:03:32Z

qiskit/providers/aer/backends/qasm_simulator.py

+                            raise Aererror(err_string + ', and contains ' +
+                                           'instructions not supported by ' + 
+                                           'the CH simulator.')
+                        else:


And we can remove this else as well for the same reasons exposed before

atilag · 2019-03-05T10:47:41Z