stavros11
commented
4 years ago I tried to think a bit how to implement some noise models in order to conclude the basic quality of life improvements and I would like to share some thoughts before starting the implementation.
First, if I understand correctly, in the most general case, mixtures and density matrix are equivalent in terms of computational cost: they both require keeping track of a 2^n x 2^n object. I agree with Adrian that the best approach is the density matrix, since it is easier to formalize.
The way I would implement the basic noise model with this approach is the following:
- Support channels in the
__call__of gates. If the__call__input is a state vector it will fall back to our current implementation but if it is a density matrix it would use a new einsum implementation that applies gates to density matrices asrho -> G rho G. - Add a new bitflip error gate with custom
__call__:rho -> (1 - p) rho + p X rho X. - Add a new phaseflip error gate with custom
__call__:rho -> (1 - p) rho + p Z rho Z. - Circuit execution always starts using pure state vectors and switches to density matrices when the first error gate is found. If this is the case, it continues the simulation with the density matrix.
- Extend callbacks and measurements to density matrices keeping the same API.
All this is relatively simple to code and I think relatively clean from the user perspective. My main concern is that the density matrix doubles the number of qubits, which means that we can simulate up to 13 qubits with noise on a single GPU. In that sense, would this approach be useful at all?
As always, there is a cheaper in memory / expensive in computation alternative. This would be to stick to the state vector simulator and add probabilistic gates (for bitflip would apply X with probability p, etc). Then we just re-run the simulation several times and the probabilistic gates act differently (randomly) in each run. We can also cache the configurations so that we do not repeat calculations and if we run the circuit 2^n times we get the whole thing (up to some strong assumptions). This would allow us to go up to 27 qubits on GPU with the cost of having to run many more times (not necessarily bad if GPU is fast).
@scarrazza, which approach sounds more useful?
scarrazza
AdrianPerezSalinas
Hi all, as we talked yesterday, I write some facts about noisy circuits. Google's cirq uses three different methods for simulating wavefunctions: 1) Standard wavefunction 2) Mixture: several independent wavefunctions and the probability of occuring 3) Density matrix Cirq/cirq/sim has got the files for the wf and the dm. Mixtures are defined in Cirq/cirq/protocols
I think if we want to implement noisy circuits, the optimal general approach should be 3) Density matrix. mixtures could become intractable if many errors happen.
I was playing around with this kind of tensors, an einsum strategy could work in this setting. For controlled gates, einsum would work with proper indices. On the contrary, an slicing strategy like the one in QCGPU should be done in different steps.
This can stay here until QIBO is ready to implement noisy circuits.
Cheers