- Hey everyone,
my name's Nick Bronn.
Today we're gonna talk about how this spring,
beloved single Qubit backend IBM Q armonk,
is retiring from service.
Why do we care?
Well, it turns out armonk was the first backend
with Qiskit pulse enabled for everyone.
Qiskit pulse, is the module of Qiskit
that brings the lab to the cloud.
You can do experiments from anywhere
including your own living room.
So why is armonk retiring?
Armonk is just a single Qubit
and we need to make way for bigger and better devices.
The cooling power of our large cryostats,
can cool larger devices
just as well as they can cool armonk
The classical control electronics also scales well
so that we can control multiple Qubits per cartridge.
This infrastructure can be deployed more efficiently
for larger modern backends.
In this way,
armonk shares a common fate with all backends
since IBM Quantum,
is always making improvements to not just quantum devices,
but also to cryogenics and classical control electronics.
Why do we care about Qiskit pulse?
Well, I'm an experimental physicist,
and I use pulses to play around with quantum hardware.
These pulses allow
device level characterization,
and physics experiments,
such as Qubit calibration,
and understanding the cross residents entangling gate.
Low level control allows for new kinds of optimization,
such as designing error robust single Qubit operations,
augmenting basis gate sets for optimized compiling,
reducing leakage to allow faster gates,
and pulse scaling for improved quantum simulations.
The good news is,
all Qubits now have pulse level access.
There's just a different way of using it,
and we'll show how in this video.
The open pulse language specification,
was released in 2018.
But the way it's used in Qiskit has varied quite a bit.
Now let's take a walk
down the memory lane of Qiskit pulse syntax,
and highlight how pulse was used in the past,
and how to interface with in the future.
For those of you following a long at home,
this is based on the textbook chapter,
Calibrating Qubits with Qiskit Pulse.
A link to this notebook is also providing the description.
For demonstration,
we're gonna be doing a spectroscopy experiment,
where we find the Qubit frequency
by sweeping the frequency of a probe excitation pulse.
First, let's load all the necessary Qiskit libraries.
You'll see, we import pulse here
as well as some components of pulse,
such as channels, instructions and schedules.
Also predefined pulse shapes like Gaussian are here as well.
Then make sure your graphical style
looks good on a dark background.
In a separate video,
we'll talk about tailoring your circuits and pulse schedules
for presentations and publications.
Next, we'll load our account on the open group,
which everyone has access to.
Then we'll check that armonk supports open pulse
by asking the backend configuration.
True.
Next we'll select our Qubit
and define some constants we'll be needing.
Now, let's define a range of frequencies
for the spectroscopy experiment.
We'll go in range of a hundred megahertz
around the Qubit center frequency
that we'll retrieve from the backend.
This defines a sweep
from 4.922 gigahertz,
to 5.022 gigahertz.
A convenient thing you can do in pulse,
is get the settings that are calibrated on the backend,
through the instruction schedule map.
Here we obtain the pulse schedule for an x gate,
as well as the measurement pulse.
Schedules are built from instructions.
And here's the archaic symbology
for constructing these schedules.
Here, plus stands for appending schedules,
the bar symbol stands for merging symbols,
and the less than signs,
allow you to shift forward in time by a given amount.
Let's demonstrate this by building an empty schedule
and merging it with the x gate schedule
which we use as our prop pulse.
Then merging the measurement schedule
shifted by the duration of the x gate
so that the measurement occurs after the prop pulse.
Take a look by drawing the schedule.
We see the prop pulse in blue
and the measurement pulses in red,
played on different channels,
and offset in a cycle time determined
by the waveform generators on the x-axis.
The following reflects the older style of pulse.
We use the same schedule,
but past our frequency range,
to the assemble method
so that the frequency is swept.
In Qiskit pulse,
we refer to the frequency of our pulse
as the local oscillator frequency.
When the LO frequency is the same as the Qubit frequency,
we excite the Qubit and observe this excitation.
This is how we determine the Qubit's frequency,
via this spectroscopy experiment.
This creates a quantum object,
that we can send to our backend.
However, this method is deprecated
and we'll show later how to run these in the future.
Now run the job, and we can observe our progress
on this IBM Q jobs widget.
Oh, it looks like we're already running.
Job is actively running.
And it's run.
Let's retrieve the results from the job,
and we'll take the real part of the results
since it's complex data.
Next, we wanna plot our results
but also make a fit to that plot,
to determine our Qubit's frequency.
We'll use the optimized library
from the scipy module to write a fit function,
to a lorentzian curve.
This takes the x and the y data,
and provides fit parameters
from which the fit function can be reconstructed.
And then we'll define the lorentzian,
the type of curve we expect to get from our results.
And then we'll do the fit given some initial guesses.
Plotting the data in fit,
gives us a measured frequency of 4.972 gigahartz,
not surprisingly,
exactly the same thing the backend provided us.
Now let's redo the experiment in armonk
but using the modern pulse syntax.
This time we'll create a list of schedules.
I prefer to use a frequency offset,
because I know the local oscillator frequency,
is already set to that of the Qubit.
For each frequency offset,
enter the pulse builder context
to align pulses sequentially,
and then to shift the LO frequency for each offset
on our drive channel.
Then we'll call the same X gate,
but each schedule will get a different frequency.
And then we'll pin that schedule,
to the list of schedules
and draw the last schedule.
We got the same thing as last time.
But notice this time
we have frequency information in the schedule.
In particular, this is our last schedule
so that our probe Qubit frequency has been shifted up
by 50 megahertz.
Now we just run the job,
and we see our job has been validated,
and now it's running.
Now just retrieve the results,
fit the job similarly,
and see that we measured 4.971 gigahertz,
just about what we expected.
Now, let's talk about pulse gates,
through which every user,
has pulse access to every Qubit.
Let's try this out on ibmq_belem.
We can see that it does not have open pulse
which means we cannot send schedules directly
to this backend.
However, we can attach schedules to gates
via pulse gates and send those
which allows us to do equivalent experiments
as we did to armonk.
We can still get the X gate from belem,
from the instruction schedule map.
Let's compare this to the X gate on armonk.
We can see the X gate is much larger
on armonk than it is on belem.
This is because it takes more energy,
to do the same operation.
Hence we say armonk is under coupled.
In order to use pulse gates,
we need to express our experiment as a circuit.
So we need to install the circuit libraries
from Qiskit.
We'll create a circuit
consisting of an X gate as our probe excitation,
followed by a measurement pulse as before.
Then we need to create the necessary schedule
and attach it to our X gate
for each frequency offset
we wanna use in our spectroscopy sweep.
However, now we have a list of circuits
instead of schedules.
The dot add_calibration
tells the backend to play the schedule, sched,
we made whenever it comes across
an X gate on Qubit zero.
We can also look at the calibrations for each circuit,
and see that the 50 megahertz shift on the last circuit,
is reflected by the shift frequency instruction.
Let's run this job on belem in the same way.
We can see that we're queued up.
Let's retrieve the data again,
write the fit function,
and plot it all together.
And this time we see the Qubit frequency as 5.09 gigahertz.
And that makes sense.
We just measured a different Qubit.
Note that a new module called Qiskit experiments
allows you to generate such experiments
without starting from the Qiskit pulse level.
We'll put a link for this in the description below.
We have a library of experiments that can be performed
including verification experiments,
characterization experiments,
and calibration experiments,
such as the spectroscopy one we just performed
which goes by RoughFrequencyCal here.
A good place to get started,
is the experiments tutorials.
In this video,
we've done three different spectroscopy experiments.
The first using archaic open pulse syntax on armonk
the second using modern open pulse syntax,
using the pulse builder.
And finally, the current and future method
of using pulse gates,
which are pulse schedules added to gates
in a quantum circuit.
I've been your host, Nick Bronn.
And with that,
I'd like to say farewell to armonk,
and long live Qiskit pulse.