qw11q line B

[stavros11]

Since we could not work with line A, we decided to also connect line B to QM and the corresponding TWPA was calibrated today by the lab. All resonators show flux dependence, however the sweetspots of two of the qubits seem to be beyond reach. I have not tried to find the qubits yet, I will try to continue tomorrow.

• Punchout: http://login.qrccluster.com:9000/WMQxKzqoTMOt2kevAI8KTg==
• Resonator spectroscopy: http://login.qrccluster.com:9000/XjRCS2QcSGy0HoRZlyupNw==
• Resonator flux: http://login.qrccluster.com:9000/wv5cmKhuQuy7gmK-APtTrA==

Note that line B and line D (the other working line in this chip) do not share connections for two-qubit gates, so they could also be operated as two separate 5q chips. For now I decided to put everything in the same platform and also still keep A, because this provides the most information. Depending on how we eventually operate this, we may want to drop A and split B and D to two separate platforms. This may slightly speed up scripts as it won't need to perform health check on all 5 octaves every time, however it won't be possible to address both B and D in parallel in the same script (now it is). Also, if there is crosstalk between B and D (not investigated yet), parameters may be slightly affected when using one vs two platforms.

[stavros11]

Latest status:

1. B1cannot do Rabi
2. B2 97%
3. B3 93%
4. B4 cannot reach sweetspot with QM
5. B5 96%

• Single shot: http://login.qrccluster.com:9000/PHN0E_aeRYeMOQ-j_S1DNQ==
• Rabi: http://login.qrccluster.com:9000/MLMrVJ96TXue_ZdgX4c6ng==

[Edoardo-Pedicillo]

I have tested the platform and it is working except with standard rb: when a circuit with the same number of qubits of the chip is executed on hardware, an error is raised:

RuntimeError: Cannot establish connection to
 <qibolab.instruments.rohde_schwarz.SGS100A object at 0x7fee563e8bb0> 
instruments. Error captured: ''Another instrument has the name: twpaB''.

Here the full log: out.log.

Just for the context, this is the runcard (it is just a test of the protocol):

platform: qw11q
targets: ["D2"]


actions:

  - id: standard rb
    operation: standard_rb
    parameters:
        depths: [1, 5]
        niter: 2
        nshots: 500
        seed: 1234

and these the commits:

• qibocal: qiboteam/qibocal@3df6ccd (branch fix_padding run transpiled circuit in platform with generic QubitId qibocal#940)
• qibolab: qiboteam/qibolab@11a34bd
• qibo: qiboteam/qibo@713efb2
• qibolab_platform_qrc: 217b004

I am not sure, if it is related to this specific platform or qibolab (@alecandido @stavros11, what do you think ?), btw for the rest the calibration is good enough and we could merge this PR.

[alecandido]

I could reproduce the issue, and it is most likely specific for this platform. I'm investigating

alecandido/qrc@5923313

[alecandido]

I have to investigate in greater details, but the problem seems to be related to just the RB.

Essentially, it seems that the RB is trying to instantiate a new platform and connect it, without disconnecting the already connected one.

For this reason, new_platform.connect() is actually attempting a connection (which would not happen with original_platform.connect(), since platform.is_connected = True), and the Qcodes driver of the LO complains that an instrument with that name is already registered.

It could also be that there is a single platform around, but the platform.disconnect() is not unregistering the LO (which would be more strange, but I didn't explore enough to exclude).

[Edoardo-Pedicillo]

Since the issue is only about Qibocal, we can merge this PR.