Emulator upgrades to come

[jykhoo1987]

To-do list:

• [x] 1) Add flux pulse simulation

Multi-qubit models:

• [ ] 2) Synchronize with Qibolab team for best place to host additional parameters (possibly runcard under characterization, pairs or couplers) including:

• coupling strength parameters (qubit-qubit and qubit-coupler interaction strengths)

• flux quantum for each qubit and coupler

• maximum frequency for each qubit and coupler

• [x] 3) Add models with couplers

• [ ] 4) Resolve outstanding issue regarding discrepancy between simulating cross resonance pulse/gate based on effective Hamiltonian and full Hamiltonian

  Simulation acceleration/library updates

• [ ] 5) Add qutip 5.0 simulation engine with jax support

• [ ] 6) Update to qibolab 0.2.0 when released

  Measurements:

• [ ] 7) Add simple resonator emulation

[jykhoo1987]

For item 2, I have discussed with @sorewachigauyo and I believe these are the additional device specific inputs required by the simulation model. Are you agreeable that these parameters be added to parameters.json? @stavros11 @alecandido @andrea-pasquale

[alecandido]

I believe the most important item at this point is emulating a readable qubit - i.e., add the resonator emulation.

For item 2, I have discussed with @sorewachigauyo and I believe these are the additional device specific inputs required by the simulation model. Are you agreeable that these parameters be added to parameters.json?

As it is already, whatever is device specific, can be added as a section in the instruments configs in parameters.json. Instead, whatever is not device specific should not be duplicated there :)

[sorewachigauyo]

As it is already, whatever is device specific, can be added as a section in the instruments configs in parameters.json. Instead, whatever is not device specific should not be duplicated there :)

The parameters to be added are needed for the emulator to function, especially for two qubit interactions and flux pulses, but they are also real parameters of the qubit device. I would say they are not explicitly instrument configurations.

I think that there's been a bit of confusion, but my suggestion was for these parameters to be added to the Qubit, QubitPair and Coupler objects. Naturally, these have to be added to parameter.json in the characterization section, which was the source of the confusion.

I believe the most important item at this point is emulating a readable qubit - i.e., add the resonator emulation.

I don't think that this is the most important at our current stage, given that different chips have different readout designs (purcell filters, etc.), which would require more description of the chip than what we have currently have. I agree that this is an important point, since readout fidelity is critical in every possible application.

I can come up with a base model for this given the chips that you have and that we are making, and we can try to pursue this on the side and eventually merge into this emulator.

With the flux pulse simulation, we can simulate the CZ/iSWAP interactions, which should speed up the calibrations of the chevrons by providing a good guess for the initial region. I believe that this would be a good first approach on bridging the emulator and the lab.

[alecandido]

I don't think that this is the most important at our current stage, given that different chips have different readout designs (purcell filters, etc.), which would require more description of the chip than what we have currently have. I agree that this is an important point, since readout fidelity is critical in every possible application.

To be fair, I'm not much worried about emulating specific chips in the first place, but rather having a working emulation for testing and improving protocols. Your observation still applies: you should take into account different resonators in order to have the most optimal infrastructure. Still, any resonator is better than no resonator. And my idea of "a" resonator is just the bare Jaynes-Cummings Hamiltonian. As a first option, nothing more fancy than that.

With the flux pulse simulation, we can simulate the CZ/iSWAP interactions, which should speed up the calibrations of the chevrons by providing a good guess for the initial region. I believe that this would be a good first approach on bridging the emulator and the lab.

I'm not sure whether focusing on multiple qubits immediately is truly the way to go. Just because it will considerably complicate the simulation, so I'd prefer everything to be clean and minimal before getting there (just to avoid a disposable emulator).

My understanding is that if you know the parameters of the simulation, you should not need to simulate your interaction in order to extract a good guess. Instead, you should be able to compute it (i.e. without performing an iterative evolution). In fact, I imagine the simulation to be most useful in the context in which you're trying to understand the details of your model, that are hard to investigate and pinpoint experimentally because of the background noise and other limitations.

Most likely, I'm missing something of your perspective.

[sorewachigauyo]

To be fair, I'm not much worried about emulating specific chips in the first place, but rather having a working emulation for testing and improving protocols. Your observation still applies: you should take into account different resonators in order to have the most optimal infrastructure. Still, any resonator is better than no resonator. And my idea of "a" resonator is just the bare Jaynes-Cummings Hamiltonian. As a first option, nothing more fancy than that.

Sure, I will draft something for that.

I'm not sure whether focusing on multiple qubits immediately is truly the way to go. Just because it will considerably complicate the simulation, so I'd prefer everything to be clean and minimal before getting there (just to avoid a disposable emulator).

The thing is that the emulator already includes the qubit-qubit interactions, it's just that without the addition of the flux pulses, they are just simply static coupling.