qiboteam / qibolab_platforms_qrc Goto Github PK

I think that to make things simple we should have the same names between platforms and partitions in cluster.
If the only reason for maintaining qw5q_gold is to store the qmconfiguration we can always recover it looking at the history of the repository.

I was trying to push here a new branch, related to the new rfsoc driver and I got:

remote: Permission to qiboteam/qibolab_platforms_qrc.git denied to rodolfocarobene.

This may improve timings with executing in hardware for the monitor.

I will take a look after I can connect properly to the platform in main, as some changes in the LO ip or it being off prevents me testing qibolab after the update.

[2024.02.14 17:56:06.615] WARNING HDAWG:dev8660: Include the device options 'HDAWG8/' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.
[2024.02.14 17:56:06.795] WARNING HDAWG:dev8673: Include the device options 'HDAWG4/' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.
[2024.02.14 17:56:07.618] WARNING SHFQC/QA:dev12146: Include the device options 'SHFQC/QC6CH' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.

The main branch of this repository should contains only platforms which are currently accessible (regardless of the status of the calibration). Currently we know that spinq10q, qw5q_gold and iqm5q are operative.
What is the status of all tii* platforms @JavierSerranoGarcia @aorgazf @DavidSarlle?
If they are not operative we should remove them as soon as possible. There is no point in maintaining dead platforms in main.
Keep in mind that if we ever need those platforms again it is very easy to jump back to previous version and find them in GitHub.

As discussed in a separate meeting it would be beneficial for everyone (and especially the middleware team) to have access to all QPUs currently available in the cluster in order to test and debug Qibocal/Qibolab.
I also suggest to remove from the current main all platforms that do not agree with the current configuration of chips/electronics.
Moreover, we don't need a perfectly calibrated runcard. For now opening a draft PR (as already did by @aorgazf #80) with the correct createwill be more than enough. Eventually each person responsible for the calibration can improve the calibration directly in those PRs.
Below I put a list of the missing runcard/platforms updated after the latest warm up (feel free to edit this as soon as the PR is opened).

• qw5q_gold
• spinq10q
• iqm5q (fails when initializing instruments)
• tii1q_b1 (runcard and platform working in main but chip not calibrated)
• any RFSoC related chip

I'm using qw5q_gold_qblox in #65 and since 5 minutes ago I am getting the following error:

RuntimeError: Cannot establish connection to <qibolab.instruments.rohde_schwarz.
SGS100A object at 0x7f08bbed3610> instruments. Error captured: '[Errno 113] No r
oute to host'

Which lets me believe that probably the LO disconnected.
@aorgazf @PiergiorgioButtarini @DavidSarlle could you please check if the LO is properly connected?

@aorgazf It would be nice to be informed about that, thanks !

Recently when installing qibolab with zh extras for qw5_platinum there are still missing packages such as pyvisa and qcodes. We should document this.

@andrea-pasquale or @stavros11 could we made the bot measure T1 and RB single qubit apart from assigment fidelity ?

Monitor the status of new runcards until we apply the qibolab refactor (expected version 0.1.0).

Just as a very cheap sanity check, we should try to execute the create functions in the CI, to test that they are actually valid with some version of Qibolab.

Most likely, there is no other sensible check we could do in the CI to test the validity of create functions and runcards, because most of the content consist of parameters representing the lab.
But Qibolab compatibility could be tested, and thus we should (at least we'll avoid stale runcards).

About the version choice, there are a few options:

• use the latest release, i.e. stable
• use the latest main, i.e. latest
• use a custom version for each runcard (possibly written in a TOML file [*])
• more?

My proposal would be to use stable by default, and add the TOML file in case we want to freeze or advance some platform (e.g. to test new Qibolab features, or maintain a platform that for some reason couldn't be compatible with Qibolab stable).

[*]: TOML is suitable for configurations, and it has been added to Python standard library, so we could save the dependency on PyYAML

As discussed yesterday it would be nice to have also a runcard and a create method for the spinq chip.

I'm trying to access the TWPA frequency and power but I'm having some issues with qw5q_gold.
Using get_lo_twpa_frequency or get_lo_twpa_power I get the following error

AttributeError: 'NoneType' object has no attribute 'lo_power'

I think that it might be related to the fact that in the current main the twpa channels has a None port

Any ideas on how to solve this @aorgazf @DavidSarlle @stavros11 ?
Keep in mind that this is blocking qiboteam/qibocal#478

I'm trying to recalibrate qw5q_gold and I've seen that changing the sweetspot in the runcard does not actually change the sweetspot when running a flux experiment with qibocal.

I manage to change the sweetspot by modifying the offset in the ClusterQCM_BB_Settings

To avoid setting this value twice I think that the create_function should read the sweetspot directly from the runcard instead of hardcoding them.
What do you think @rodolfocarobene, @stavros11 @DavidSarlle ?

Introduce the profiles file with the platform's name and py files containing the create definition.

Is it necessary to set IQ for readout when using QM?
Would be possible to set the phase and measure directly I (without Q)?