GSoC 2019 QuTiP project

As we are approaching the end of this GSoC project, it is time to write a summary of the whole GSoC project. During the last two and a half months, the project basically followed the main points in the proposal and adapted the implementation details to the real situation. The final delivery of this project is a NISQ (Noisy Intermediate-Scale Quantum) simulator based on the QuTiP open system solver. It offers a framework for simulating quantum device. Three examples, the SpinChain, CavityQED and OptPulseProcessor demonstrate how to implement a concrete model. In addition,  we add a noise module as a framework for simulating device-dependent noise in the system. The main pull request is at  https://github.com/qutip/qutip/pull/1065 . This GSoC project has been the main theme of my past few months.  Before this project, my programming experience is only on home-work level and only for self-use. This is the first time that I work on a project that is going to be released and used by the o

This week was dedicated to polishing the code, writing documentation and notebooks. I collected the notebook examples I wrote in the past two months and join them into three new notebooks in  https://github.com/qutip/qutip-notebooks/pull/88 . There is one notebook for NISQ simulation, one for OptPulseProcessor and one for the Deutsch-Jozsa Algorithm. The documentation is displayed blow. Since rendering is a little bit different, the GitHub version might be easier to read( https://github.com/BoxiLi/qutip-doc/blob/qip_doc/guide/guide-qip.rst ) Quantum Information Processing .. ipython:: :suppress: In [1]: from qutip import * In [1]: import numpy as np Introduction The Quantum Information Processing (QIP) module aims at providing basic tools for quantum computing simulation both for simple quantum algorithm design and for experiment realization. It offers two different approaches, one with :class:`qutip.qip.QubitCircuit` calculating unitary evolution u

Now we have the main ingredients for this project: CircuitProcessor as the simulator and CircuitNoise representing noise, it's time to go back and fix some technical issues. There were two unsolved problems discussed in the posts before: QuTiP solver interprets the array-like coefficients as smooth function and uses a cubic spline interpolation by default. However, as mentioned in  the previous blog , in CircuitProcessor we use the coefficients as a step function, i.e. coeff = [1,2,3] means that the pulse amplitude is 1 during t=[0,1), 2 during t=[1,2) and so on. This causes a mismatch in the result and was only solved temporarily by using Python function as coefficients. The solver requires that all the coefficients have the same tlist , which makes it difficult to add noise to the processor since the noise might have a different frequency. This was mentioned at the end of the last post . To solve the first problem we need to modify the solvers. Fortunately, the recent up

We are now at the point to include noise into the simulation. The decoherent noise characterized by T1 and T2 time has already been implemented, but we want to generalize it to different types of noises and separate it from the processor class. The above flowchart is from the blog of last week, where I wrote some of my thinking about the noise that we are dealing with. After some discussion and study, I now have a relatively complete view of the noise objects. The figure above shows how the noise is processed in the circuit processor.  The noise is defined separately in a class object. When called, it takes parameters from the processor (like operators or coefficients), modifies them and returns them to the processor. However, this design has a drawback. Since the Hamiltonian saved in the circuitprocessor is a list of operators and their amplitudes. It restricts the form of the noise, for instance, it is not possible to create noise with coefficient represented by string based func

It was suggested that we separate the noise from the circuit processor. So I decided to first make it clear where does the noise play a role in our model and try to find a good way to define a noise object. In the simulation, I find two places to introduce noise: The first one is the collapse operator, it has been an important part of the open system solver from the beginning of QuTiP and can be naturally added into our simulation. the T1 and T2 time added recently is basically just a wrap for it. Noise from the instrument. Parameters like a detuned frequency can be simulated by simply perturbing it in the definition of  cqed and spinchain The first one is quite clear, what I'm not sure about is the second one. Two issues: How should we define this perturbation in a separate noise object? To represent the noise in the instruments, I'm thinking of a time-dependent experiment parameter (e.g. frequency, interaction strength etc). Like we now have for the amplitude, it w

The main tasks of the last two weeks were refactoring the existing code and finding a way to simulate noise. The original CircuiProcessor class is now the base class calling the open system solver and calculating the numerical evolution. On top of this, the subclasses determine how to find the driving pulses for a given quantum circuit. We aimed at bring other part of the code in qip under the same structure described in  the previous post . so that the class structure looks like: CircuitProcessor ├── ModelProcessor │ ├── DispersivecQED │ └── SpinChain └── OptPulseProcessor There are two main parts of the refactoring. First, cqed and   spinchain were designed for specific models, each Hamiltonian operator and control pulse amplitude has a separate attribute in the class. To unify the representation, I used the property decorator in Python to link them to the two main attributes ctrls and amps , to be consistent with the parent class  circuitprocessor. In this way, The

User defined gate In [1]: from qutip import * import numpy as np User defined gates ¶ This demo is based on the branch https://github.com/BoxiLi/qutip/tree/user_gate A user defined gate can be specified by a python function that takes at most one parameter and return a Qobj , the dimension of the Qobj has to match the qubit system. In [2]: def user_gate1 ( arg_values ): # controlled rotation X mat = np . zeros (( 4 , 4 ), dtype = np . complex ) mat [ 0 , 0 ] = mat [ 1 , 1 ] = 1. mat [ 2 : 4 , 2 : 4 ] = rx ( arg_values ) return Qobj ( mat , dims = [[ 2 , 2 ], [ 2 , 2 ]]) def user_gate2 (): # T gate mat = np . array ([[ 1. , 0 ], [ 0. , 1. j ]]) return Qobj ( mat , dims = [[ 2 ], [ 2 ]]) To let the QubitCircuit process those gates, one can modify its the attributes QubitCircui