From 791560f1dcc485d8fb3a1b97c3c6d28bce1d68c9 Mon Sep 17 00:00:00 2001 From: Phillip Weinberg Date: Wed, 20 Sep 2023 23:20:08 -0400 Subject: [PATCH] fixing colors and running linter --- docs/docs/examples/example-1-floquet.py | 34 ++++++------ docs/docs/examples/example-1-rabi.py | 55 ++++++++++--------- docs/docs/examples/example-1-ramsey.py | 18 +++--- .../example-2-multi-qubit-blockaded.py | 4 +- .../examples/example-2-two-qubit-adiabatic.py | 26 ++++----- docs/docs/examples/example-3-time-sweep.py | 6 +- docs/docs/examples/example-5-MIS-UDG.py | 2 +- 7 files changed, 74 insertions(+), 71 deletions(-) diff --git a/docs/docs/examples/example-1-floquet.py b/docs/docs/examples/example-1-floquet.py index ec56948..0b2f073 100644 --- a/docs/docs/examples/example-1-floquet.py +++ b/docs/docs/examples/example-1-floquet.py @@ -18,9 +18,9 @@ # # Single Qubit Floquet Dynamics # ## Introduction # Rounding out the single qubit examples we will show how to generate a Floquet -# protocol. We will define the probotol using a python function and then use the -# Bloqade API to sample the function at certain intervals to make it compatible with -# the hardware, which only supports piecewise linear/constant functions. First let us +# protocol. We will define the probotol using a python function and then use the +# Bloqade API to sample the function at certain intervals to make it compatible with +# the hardware, which only supports piecewise linear/constant functions. First let us # start with the imports. # %% @@ -31,14 +31,14 @@ # %% [markdown] # ## Define the program. -# For the floquet protocol we keep We do the same Rabi drive but allow the detuning to -# vary sinusoidally. We do this by defining a smooth function for the detuning and then -# sampling it at certain intervals (in this case, the minimum hardware-supported time -# step). Note that the `sample` method will always sample at equal to or greater than -# the specified time step. If the total time interval is not divisible by the time -# step, the last time step will be larger than the specified time step. Also note that +# For the floquet protocol we keep We do the same Rabi drive but allow the detuning to +# vary sinusoidally. We do this by defining a smooth function for the detuning and then +# sampling it at certain intervals (in this case, the minimum hardware-supported time +# step). Note that the `sample` method will always sample at equal to or greater than +# the specified time step. If the total time interval is not divisible by the time +# step, the last time step will be larger than the specified time step. Also note that # the arguments of your function must be named arguments, e.g. no `*args` or `**kwargs`, -# because Bloqade will analyze the function signature to and generate variables for +# because Bloqade will analyze the function signature to and generate variables for # each argument. # %% @@ -62,7 +62,7 @@ def detuning_wf(t, drive_amplitude, drive_frequency): ) # %% [markdown] -# We assign values to the necessary variables and then run_async the program to both +# We assign values to the necessary variables and then run_async the program to both # the emulator and actual hardware. # %% @@ -77,15 +77,15 @@ def detuning_wf(t, drive_amplitude, drive_frequency): ).batch_assign(run_time=run_times) # %% [markdown] -# have to start the time at 0.05 because the hardware does not support anything less +# have to start the time at 0.05 because the hardware does not support anything less # than that time step. We can now run_async the job to the emulator and hardware. # %% [markdown] # ## Run Emulator and Hardware # Like in the first tutorial, we will run the program on the emulator and hardware. # Note that for the hardware we will use the `parallelize` method to run multiple -# copies of the program in parallel. For more information about this process, see the -# first tutorial. +# copies of the program in parallel. For more information about this process, see the +# first tutorial. # %% emu_filename = os.path.join(os.path.abspath(""), "data", "floquet-emulation.json") @@ -102,8 +102,8 @@ def detuning_wf(t, drive_amplitude, drive_frequency): # %% [markdown] # ## Plotting the Results -# Exactly like in the Rabi Oscillation example, we can now plot the results from the -# hardware and emulation together. Again we will use the `report` to calculate the mean +# Exactly like in the Rabi Oscillation example, we can now plot the results from the +# hardware and emulation together. Again we will use the `report` to calculate the mean # Rydberg population for each run, and then plot the results. # # first we load the results from the emulation and hardware. @@ -115,7 +115,7 @@ def detuning_wf(t, drive_amplitude, drive_frequency): # save(filename, hardware_batch) # %% [markdown] -# Next we extract the run times and the Rydberg population from the report. We can then +# Next we extract the run times and the Rydberg population from the report. We can then # plot the results. # %% diff --git a/docs/docs/examples/example-1-rabi.py b/docs/docs/examples/example-1-rabi.py index f17027e..c3fc928 100644 --- a/docs/docs/examples/example-1-rabi.py +++ b/docs/docs/examples/example-1-rabi.py @@ -17,10 +17,10 @@ # %% [markdown] # # Single Qubit Rabi Oscillations # ## Introduction -# In this example we show how to use Bloqade to emulate Rabi oscillations of a Neutral -# Atom and run it on hardware. We will define a Rabi oscillation as a sequence with a -# constant detuning and Rabi frequency. In practice, the Rabi frequency has to start -# and end at 0.0, so we will use a piecewise linear function to ramp up and down the +# In this example we show how to use Bloqade to emulate Rabi oscillations of a Neutral +# Atom and run it on hardware. We will define a Rabi oscillation as a sequence with a +# constant detuning and Rabi frequency. In practice, the Rabi frequency has to start +# and end at 0.0, so we will use a piecewise linear function to ramp up and down the # Rabi frequency. # %% @@ -28,13 +28,14 @@ import os import matplotlib.pyplot as plt import numpy as np + # %% [markdown] # ## Define the program. -# Below we define program with one atom, with constant detuning but variable Rabi -# frequency, ramping up to "rabi_ampl" and then returning to 0.0. Note that the `cast` -# function can be used to create a variable that can used in multiple places in the -# program. These variables support basic arithmetic operations, such as addition, -# subtraction, multiplication, and division. They also have `min` and `max` methods +# Below we define program with one atom, with constant detuning but variable Rabi +# frequency, ramping up to "rabi_ampl" and then returning to 0.0. Note that the `cast` +# function can be used to create a variable that can used in multiple places in the +# program. These variables support basic arithmetic operations, such as addition, +# subtraction, multiplication, and division. They also have `min` and `max` methods # that can be used in place of built-in python `min` and `max` functions, e.g. # `cast("a").min(cast("b"))`. @@ -71,11 +72,11 @@ # %% [markdown] # ## Run Emulator and Hardware -# To run the program on the emulator we can select the `braket` provider as a property +# To run the program on the emulator we can select the `braket` provider as a property # of the `batch` object. Braket has its own emulator that we can use to run the program. -# To do this select `local_emulator` as the next option followed by the `run` method. +# To do this select `local_emulator` as the next option followed by the `run` method. # Then we dump the results to a file so that we can use them later. Note that unline the -# actual hardware the shots do not correspond to multiple executions of the emuatlor, +# actual hardware the shots do not correspond to multiple executions of the emuatlor, # but rather the number of times the final wavefunction is sampled. This is because the # emulator does not simulate any noise. @@ -88,23 +89,23 @@ save(emu_batch, emu_filename) # %% [markdown] -# When running on the hardware we can use the `braket` provider. However, we will need -# to specify the device to run on. In this case we will use *Aquila* via the `aquila` -# method. Before that we must note that because Aquila can support up to 256 atoms in -# an area that is $75 \times 76 \mu m^2$. We need to make full use of the capabilities +# When running on the hardware we can use the `braket` provider. However, we will need +# to specify the device to run on. In this case we will use *Aquila* via the `aquila` +# method. Before that we must note that because Aquila can support up to 256 atoms in +# an area that is $75 \times 76 \mu m^2$. We need to make full use of the capabilities # of the device. Bloqade automatically takes care of this with the `parallelize` method, -# which will allow us to run multiple copies of the program in parallel using the full -# user provided area of Aquila. The `parallelize` method takes a single argument, which -# is the distance between each copy of the program on a grid. In this case, we want to -# make sure that the distance between each atom is at least 24 micrometers, so that the -# Rydberg interactions between atoms are negligible. -# -# To run the program but not wait for the results, we can use the `run_async` method, -# which will return a `Batch` object that can be used to fetch the results later. After +# which will allow us to run multiple copies of the program in parallel using the full +# user provided area of Aquila. The `parallelize` method takes a single argument, which +# is the distance between each copy of the program on a grid. In this case, we want to +# make sure that the distance between each atom is at least 24 micrometers, so that the +# Rydberg interactions between atoms are negligible. +# +# To run the program but not wait for the results, we can use the `run_async` method, +# which will return a `Batch` object that can be used to fetch the results later. After # running the program, we dump the results to a file so that we can use them later. Note -# that if you want to wait for the results in the python script just call the `run` -# method instead of `run_async`. This will block the script until all results in the -# batch are complete. +# that if you want to wait for the results in the python script just call the `run` +# method instead of `run_async`. This will block the script until all results in the +# batch are complete. # %% hardware_filename = os.path.join(os.path.abspath(""), "data", "rabi-job.json") diff --git a/docs/docs/examples/example-1-ramsey.py b/docs/docs/examples/example-1-ramsey.py index 537e1da..ee97b98 100644 --- a/docs/docs/examples/example-1-ramsey.py +++ b/docs/docs/examples/example-1-ramsey.py @@ -17,11 +17,11 @@ # %% [markdown] # # Single Qubit Ramsey Protocol # ## Introduction -# In this example we show how to use Bloqade to emulate a Ramsey protocol as well as -# run it on hardware. We will define a Ramsey protocol as a sequence of two $\pi/2$ -# pulses separated by a variable time gap $\tau$. These procols are used to measure the -# coherence time of a qubit. In practice, the Rabi frequency has to start and end at -# 0.0, so we will use a piecewise linear function to ramp up and down the Rabi +# In this example we show how to use Bloqade to emulate a Ramsey protocol as well as +# run it on hardware. We will define a Ramsey protocol as a sequence of two $\pi/2$ +# pulses separated by a variable time gap $\tau$. These procols are used to measure the +# coherence time of a qubit. In practice, the Rabi frequency has to start and end at +# 0.0, so we will use a piecewise linear function to ramp up and down the Rabi # frequency. @@ -69,8 +69,8 @@ # ## Run Emulation and Hardware # Like in the first tutorial, we will run the program on the emulator and hardware. # Note that for the hardware we will use the `parallelize` method to run multiple -# copies of the program in parallel. For more information about this process, see the -# first tutorial. +# copies of the program in parallel. For more information about this process, see the +# first tutorial. # %% emu_filename = os.path.join(os.path.abspath(""), "data", "ramsey-emulation.json") @@ -85,8 +85,8 @@ # %% [markdown] # ## Plot the results -# Exactly like in the Rabi Oscillation example, we can now plot the results from the -# hardware and emulation together. Again we will use the `report` to calculate the mean +# Exactly like in the Rabi Oscillation example, we can now plot the results from the +# hardware and emulation together. Again we will use the `report` to calculate the mean # Rydberg population for each run, and then plot the results. # # first we load the results from the emulation and hardware. diff --git a/docs/docs/examples/example-2-multi-qubit-blockaded.py b/docs/docs/examples/example-2-multi-qubit-blockaded.py index e60874d..8c8f6f2 100644 --- a/docs/docs/examples/example-2-multi-qubit-blockaded.py +++ b/docs/docs/examples/example-2-multi-qubit-blockaded.py @@ -21,7 +21,7 @@ # perform multi-qubit blockaded Rabi oscillations. The Physics here is described in # detail in the [whitepaper](https://arxiv.org/abs/2306.11727). But in short, we can # use the Rydberg blockade to change the effective Rabi frequency of the entire system -# by adding more atoms to the cluster. +# by adding more atoms to the cluster. # %% from bloqade import start, save, load @@ -81,7 +81,7 @@ # ## Defining the Program # Now, all that is left to do is to compose the geometry and the Pulse sequence into a # fully defined program. We can do this by calling the `apply` method on the geometry -# and passing in the sequence. This method will return an object that can then be +# and passing in the sequence. This method will return an object that can then be # assigned parameters. # %% batch = ( diff --git a/docs/docs/examples/example-2-two-qubit-adiabatic.py b/docs/docs/examples/example-2-two-qubit-adiabatic.py index 8a12332..3396573 100644 --- a/docs/docs/examples/example-2-two-qubit-adiabatic.py +++ b/docs/docs/examples/example-2-two-qubit-adiabatic.py @@ -18,7 +18,7 @@ # # Two Qubit Adiabatic Sweep # ## Introduction # In this example, we show how to use Bloqade to program an adiabatic sweep on a pair of -# atoms, with the distance between atoms gradually increasing per task. This will allow +# atoms, with the distance between atoms gradually increasing per task. This will allow # us to explore the effect of the Rydberg interaction. We will run the program on both # the emulator and the hardware to compare the results. # %% @@ -32,18 +32,18 @@ # %% [markdown] # ## Defining the Program -# Now, we define our program of interest. For an adiabatic protocol, we keep that Rabi -# frequency at a considerable value while slowly ramping the detuning from a large -# negative to a positive value. The idea is that when the detuning is large and -# negative the atoms remain in the ground state. As the detuning is ramped to positive -# values, the atoms are able to be excited to the Rydberg state, however if the atoms -# are too close together, the Rydberg interactions effectively acts like a negative -# etuning to neighboring atoms, preventing them from being excited. This is the -# blockade effect. For atoms that are sufficiently far apart, the Rydberg interaction -# is negligible and the atoms can be excited to the Rydberg state. As the atoms get -# closer together, the Rydberg interaction becomes more significant the probability of -# exciting both atoms becomes smaller. The typical length scale for the cross over from -# the non-interacting to the blockade regime is the blockade radius. +# Now, we define our program of interest. For an adiabatic protocol, we keep that Rabi +# frequency at a considerable value while slowly ramping the detuning from a large +# negative to a positive value. The idea is that when the detuning is large and +# negative the atoms remain in the ground state. As the detuning is ramped to positive +# values, the atoms are able to be excited to the Rydberg state, however if the atoms +# are too close together, the Rydberg interactions effectively acts like a negative +# etuning to neighboring atoms, preventing them from being excited. This is the +# blockade effect. For atoms that are sufficiently far apart, the Rydberg interaction +# is negligible and the atoms can be excited to the Rydberg state. As the atoms get +# closer together, the Rydberg interaction becomes more significant the probability of +# exciting both atoms becomes smaller. The typical length scale for the cross over from +# the non-interacting to the blockade regime is the blockade radius. # # Note that you can perform arithmetic operations directly on variables in the program # but this requires the variable to be explicitly declared by passing a string to the diff --git a/docs/docs/examples/example-3-time-sweep.py b/docs/docs/examples/example-3-time-sweep.py index e86f79c..ce7fcda 100644 --- a/docs/docs/examples/example-3-time-sweep.py +++ b/docs/docs/examples/example-3-time-sweep.py @@ -143,8 +143,10 @@ def get_z2_probabilities(report): hardware_sweep_times = hardware_report.list_param("sweep_time") -plt.plot(emu_sweep_times, emu_probabilities, label="Emulator") -plt.plot(hardware_sweep_times, hardware_probabilities, label="Hardware") +plt.plot(emu_sweep_times, emu_probabilities, label="Emulator", color="#878787") +plt.plot( + hardware_sweep_times, hardware_probabilities, label="Hardware", color="#6437FF" +) plt.show() # %% [markdown] diff --git a/docs/docs/examples/example-5-MIS-UDG.py b/docs/docs/examples/example-5-MIS-UDG.py index 6e9e26f..9989c73 100644 --- a/docs/docs/examples/example-5-MIS-UDG.py +++ b/docs/docs/examples/example-5-MIS-UDG.py @@ -99,7 +99,7 @@ ) final_detunings = report.list_param("final_detuning") -plt.plot(final_detunings, average_rydberg_excitation) +plt.plot(final_detunings, average_rydberg_excitation, color="#6437FF") plt.xlabel("final detuning (rad/µs)") plt.ylabel("total rydberg excitations") plt.show()