Annealing software from a user perspective

[fabiques]

In an annealing protocol there are no gates. There are a set of functions (in practice voltages or currents) $v_i(t)$ where $i$ corresponds to a flux channel. Typically they are linear ramps but not necessarily. At the end of the schedule we measure each qubit. In able to reconstruct the final state, one measurement is not enough and we need to repeat the the full thing N times.

With this in mind I propose we define the annealing schedules as 2D numpy array. The first index would relate to an AWG channel while the second is the time.

The scripts could look something like.

platform.build_platform("Mordor_Annealing") # Connect to devices and set parameters
annealing_schedule = np.array([np.linspace(0, end_voltage, 5000) for end_voltage in voltages])

settings = ExperimentSettings(repetitions = 1000)
experiment = AnnealingExperiment(name = 'annealing', settings=settings) # Not sure if there should be a specific annealing 
# The annealing runs the schedule and measures. Variations of this could exist. May be worth to use the intermediate representation

experiment.load_annealing_schedule(annealing_schedule) # This loads the schedule on to the awg

results = experiment.run()

It is extremely important to be able to sweep parameters of the annealing schedule, things like the slope of the ramp or end the point. In this scenario I purpose that we load a new sequence every step. For example, if we want to finish on a different point each time:

sweep_list = [annealing_schedule[:,:ii] for ii in range(1,annealing_schedule.shape[-1])]
loop = Loop(alias=?,parameter=Parameter.SCHEDULE, values=sweep_list)

There are corrections that need to be made to the schedules, in particular and most importantly, the crosstalk. These would be done completely outside of the class structure of qililab. It would be a transformation like:

corrected_schedule = correct_crosstalk(annealing_schedule, crosstalk_matrix)

Any quality of life improvements should be built on top of this.

This are preliminary ideas. Please let me know if it makes sense.

[fabiques]

@AlbertMitjans This can be a kick starter for this Friday's meeting.

[AlbertMitjans]

THIS IS EXACTLY WHAT I WANTED!! ❤️

THANK YOU 🙏 🙌

[fabiques]

I was looking at the new quantum circuit from Vyron (https://github.com/qilimanjaro-tech/qililab/blob/main/examples/internal_circuit.py) and I think we can use it in the annealing as well

Something like:

circuit.add([0,1, 2, 3], AnnealingSchedule(schedule=annealing_schedule))
circuit.add([4, 5, 6], Measure())

Note that in my opinion qililab should not distinguish between qubit, couplers or readout. The numbers refer to awg channels, or busses (samething like that), not to qubits.

[AlbertMitjans]

We are planning on using buses / chip ports as indeces!

[fabiques]

That is great news! I prefer it that way, we can create some tools that help us keep track of the qubits on top of this.

[bakecske]

I guess in my opinion it is the ratio of v_i(t) for all i (i goes up to N) that will determine the schedule and the annealing path in the end. One has to define all the constraints as in v_i = SUM k_j * v_j which can be up to N-1 equations. Once the path is defined, one has to define the total time to go through the path, and then the speed as a function of distance along the path. So all these need to be defined in code before running the full experiment which comprises of: initialization, going along the annealing path at the set speed, and finally read out.

[fabiques]

This is crosstalk. I argue that this should not be implemented into the class structure of qililab at this stage.

[fabiques]

I just remembered that we are most likely going to need to create a new measurement protocol, this might be interesting @fedonman. The current implementation of circuit might allow it though, let me know.

Basically, it will be a flux activated readout. We need to do the typical readout procedure while simultaneously applying a flux square pulse.

Could something like this work:

circuit.add(1, SquarePulse(amplitude=1.0, duration=40),2,Measure())

What would be the syntax to make them simultaneous?

[fedonman]

Right now, we don't support it. The transpiler calculates the timings of the operations. But the timings property is already there, so we could extend the add method to something like:

circuit.add(1, SquarePulse(), start_time=40)
circuit.add(2, Measure(), start_time=40)

[fabiques]

I like that!

[paulQM]

this is kind of a hacky way of synchronizing as you need to use a new index (bus) to do one action (that contains two sub actions). But I actually like this way because if we define a delay property of each bus we are then sure that the pulses are getting to the chip simultaneously. You will just need to calibrate the delay of each line once and the code will add delays in the pulse timeline smartly so everything matches.

[AlbertMitjans]

@fedonman couldn't we use Barrier to synchronize the two operations?

[fedonman]

You are correct! This is already supported. You can do:

circuit.add((0, 1), Barrier())
circuit.add(0, SquarePulse())
circuit.add(1, Measure())

and the two operations will be synchronized.

[fabiques]

With the feedback from Vyron, I think we can clarify the syntax even a bit further:

platform = build_platform(name=runcard_name)
platform.connect()
platform.initial_setup()

annealing_schedule = np.array([np.linspace(0, end_voltage, 5000) for end_voltage in voltages]) # 
corrected_schedule = correct_crosstalk(annealing_schedule, crosstalk_matrix) # -> To make the point that this is taken care off outside

circuit = Circuit(5)
circuit.add((0,1,2), AnnealingSchedule(alias='schedule', schedule=corrected_schedule))
circuit.add((3,4), FluxMeasure())

sweep_list = [annealing_schedule[:,:ii] for ii in range(1,annealing_schedule.shape[-1])]
loop = Loop(alias=schedule,parameter=Parameter.SCHEDULE, values=sweep_list)

settings = ExperimentSettings(
    repetitions = 1000,
    loops=[loop]
)

experiment = Experiment(
    platform=platform,
    circuits=[circuit], 
    settings=settings, 
)

results = experiment.run(live_plotting=True)