Strong-coupling quantum logic of trapped ions

by Mahdi Sameti, Jake Lishman and Florian Mintert.

This repository accompanies the paper "Strong-coupling quantum logic of trapped ions", available on arXiv and in Physical Review A. The files here provide the conditions enumerated in the supplementary material in computer-readable JSON form, along with the arbitrary constraint generation code, analysis notebooks and figure data.

There are several files and directories in this repository:

• pure and thermal contain the data used to make the fidelity plot (figure 2). The data files have comments in their headers (use a text editor to open) which describe their contents.
• phase contains the data used to make the phase-space plots (figure 3), and a file phase/make.py which re-generates this same data (up to some relative tolerance). This needs QuTiP (should work with 4.4 or 4.5).
• lib is a loose collection of custom Python files that form a library for the rest of the work done here.
• generate_mathematica.py is a Python file that illustrates using the supplied library to generate the constraints presented in the paper, and can be used to generate higher-order constraints.
• analysis.nb is a Mathematica notebook that defines the custom data structures used to represent the constraints for efficient symbolic analysis.
• two_sideband.m and three_sideband.m are Mathematica script files containing the custom data representation of the constraints that are used in analysis.nb and generated by generate_mathematica.py.
• order_*.json are files containing the same constraints, but in a more open data interchange format. A full description of these files is given below, in the "JSON-formatted constraints" section.

Code requirements

Python

Everything is Python 3, and requires the standard numpy, scipy and matplotlib.

The constraint generation code uses attrs, available on pip and conda.

The code that regenerates the phase-space data uses QuTiP, which at the time of writing is only available on conda. You need something in the 4.X line, and at least 4.3.

Mathematica

Analysis and solution of the constraints was done using Mathematica 10 and 11, but very little Mathematica functionality is actually used, and it should not be too difficult to get it working with any version.

Fidelity data

The pure and thermal directories contain the data plotted in figure 2. There is no direct generation code supplied for this data, but the QuTiP time-dependent representations of the Hamiltonians for the schemes defined in the paper are in phase/make.py.

Pure-state fidelity

This is figure 2a and the directory pure.

The three files correspond to the base, η^3 and η^4 schemes presented in the paper. Within each file, there is one block of data: the 0th column is η (the Lamb–Dicke parameter); the nth column is the infidelity of the gate if the starting motional state is a pure state with n-1 phonons. For example, the first column after the η column contains the infidelities of the |0> state.

Thermal-state fidelity

This is figures 2b–d and the directory thermal.

The file thermal.dat is the 2D plots themselves. There are three different sets of data in this file, separated by two blank lines. These correspond to the base, η^3 and η^4 gates respectively. Within each data block, the data is stored in an "image-like" format; each set (separated by a single blank line) is one column in the output image. The first two columns are the log-base-10 of the Lamb–Dicke parameter (η) and the average occupancy (n-bar) of the motional mode respectively. The last column is the infidelity of the relevant gate under these conditions (actual value, i.e. not the logarithm).

The files thermal-contour-*.dat contain the data for the two contours plotted in each figure. File 0 is the base gate, 1 is the η^3 gate and 2 is the η^4 gate. Within each file, there are two sets of data, separated by a single blank line. The first set is the 10^-5 contour and the second set is the 10^-3 contour. The two columns are the same as the first two columns in thermal.dat.

Phase-space trajectories

This is figure 3 and the directory phase.

The data used to plot figure 3 is in the *.dat files. The files without contours in the name are the phase space trajectories for the corresponding rows. Within each of these two files, there are three sets of data separated by a single blank line. As before, the sets of data are the base gate, the η^3 gate and the η^4 gate respectively. The first column is the expectation of position and the second is the expectation of momentum.

The files with contours in the name contain the Wigner function data also plotted. File 1 is the base gate, 2 is the η^3 gate and 3 is the η^4 gate. Within each file, there are four sets of data, separated by a two blank lines; these correspond to the Wigner functions in order from start to finish. Within each set of data there are three contours, separated by a single blank line. The columns are the same as above.

The data files in this directory can be regenerated using make.py. This file requires QuTiP, and the lib directory in this repository must be visible to Python when running it. make.py contains QuTiP time-dependent representations of the Hamiltonians of the three schemes given in the paper, which may be useful if you wish to reproduce the data for the fidelity plots too.

Constraint generation

The file generate_mathematica.py illustrates using the supplied library files to generate all the constraints given in the supplementary material and in the body of the paper. It can readily be used to generate higher-order constraints than were published as well.

This file calculates the constraints in generic functional form; no assumptions about the form of the driving are made, except that the sidebands are not driven off-resonantly. When the Python constraints are "stringified" into Mathematica code, it is assumed that the functions are piecewise, periodic functions represented by sums of Fourier modes, as the simple schemes presented in the paper are.

The Mathematica file analysis.nb contains some tools for working symbolically with functions in that form, including efficient integration rules. generate_mathematica.py regenerates the files two_sideband.m and three_sideband.m, which are Mathematica script files imported by analysis.nb and contain the custom representation of the exponential driving terms. The Mathematica notebook illustrates the use of these files.

JSON-formatted constraints

The two files with pre-generated constraints in an open format are

• order_3_sidebands_2.json: the operators and their coefficients up to and including terms in eta^3. The driving field per sideband is simply f_k(t) = f_{k,0}(t), i.e. standard driving with f_{k,0} not dependent on eta.
• order_4_sidebands_3_extra.json: the operators and their coefficients up to and including terms in eta^4. The driving field per sideband is now f_k(t) = \sum_{h=0}^4 \eta^h f_{k,h}(t), where the only eta-dependence allowed is the explicit power series in the sum.

The JSON schema in each file is as follows in a modified BNF, where [x] means an array where each element is of type x, { ... } is a literal JSON object, and the string literals in JSON object specifications will always exist as labels in every occurrence of an object of that type.

root = [transformation] ;
transformation = {
    "eta": integer,
    "terms": [term_sum_element],
} ;
term_sum_element = {
    "op": operator,
    "scalar": [scalar_sum_element],
} ;
operator = {
    "Sy": 1 | 2,
    "create": integer,
    "destroy": integer,
} ;
scalar_sum_element = {
    "imaginary": 0 | 1,
    "fraction": [integer],
    "function": string,
} ;

The array elements "terms" in transformation and "scalar" in term_sum_element are to be interpreted as sums of all their elements. The array "fraction" in scalar_sum_element is always two integers, the first is the numerator, and the second is the denominator.

The object term_sum_element is a multiplication of its two parts, as is the object scalar_sum_element of its three parts.

The example operator representation {"Sy": n, "create": p, "destroy": q} represents the term S_y^n a^{\dagger p} a^q, with the creation and annihilation operators always in that order.

The example scalar_sum_element {"imaginary": 1, "fraction": [-3, 4], "function": f} represents the quantity i^1 * (-3/4) * f(t).

The "function" element is a string literal with a root element function in the following BNF grammar.

function       = integral | multiplication | conjugation | base ;
base           = "Base(" identifier ")" ;
conjugation    = "Conj(" function ")" ;
integral       = "Integral(" function ")" ;
multiplication = "Mult(" "(" function [(", " function) ...] ")" ")" ;
identifier     = "(" integer ", " integer ")" ;

The function Base((k, h)) represents the form f_{k,h}(t), which appears in the full kth sideband driving function f_k = \sum_h \eta^h f_{k,h}(t). Conj represents complex conjugate of the enclosed function, Mult is multiplication of the arguments, and Integral is the same as the {} notation in the paper, i.e.

    {x} = \int_0^t x(t_1) dt_1
    {x {y}} = \int_0^t dt_1 \int_0^{t_1} dt_2 x(t_1) y(t_2)
    ...