Zurich tii1qs_xld1000

[Jacfomg]

WIP.

[Jacfomg]

Improve:

• Move power_range into the parameters like qm
• Flipping with unrolling is quite useless without a decent batching algorithm, same one should be used for RB @stavros11 @alecandido

Check:

• Pulse amplitude above 1, it gets clipped and logs a warning
• Unrolling funny business with Discrimination

[Jacfomg]

@igres26 @stavros11 @andrea-pasquale do you have any idea if we should close this PRs for the 1q or merge them with different names for each set of instruments ?

[stavros11]

@igres26 @stavros11 @andrea-pasquale do you have any idea if we should close this PRs for the 1q or merge them with different names for each set of instruments ?

I would wait for the lab to decide what will happen to this chip. We should try to keep only platforms that exist in the lab in main, so if they warm up I would close all PRs. @alecandido @andrea-pasquale let us know if you agree.

Since this is a PR, I think it is possible to recover the state of the code at any point if needed by checking out the latest commit hash. This works even if the PR is closed and the branch is removed from GitHub.

[andrea-pasquale]

@igres26 @stavros11 @andrea-pasquale do you have any idea if we should close this PRs for the 1q or merge them with different names for each set of instruments ?

I would wait for the lab to decide what will happen to this chip. We should try to keep only platforms that exist in the lab in main, so if they warm up I would close all PRs. @alecandido @andrea-pasquale let us know if you agree.

Since this is a PR, I think it is possible to recover the state of the code at any point if needed by checking out the latest commit hash. This works even if the PR is closed and the branch is removed from GitHub.

I also agree with @stavros11. In main we should keep only "working" platform.
For sure it is possible to recover the state of the code even if we close the PR. To be able to access those previous calibration attempts easier it would be nice to have them stored somewhere else (maybe in notion) in order to build a proper archive with old calibration attempts. I believe this task should be done by the QComp/characterization team.

[igres26]

I agree that only the working platforms should be front and center in main. Maybe a good compromise is to have an "inactive" folder in main where we dump these platforms that could technically come back up. Also for ease of access of the platform files in order to build similar platforms in the future.

[Jacfomg]

@igres26 @stavros11 @andrea-pasquale do you have any idea if we should close this PRs for the 1q or merge them with different names for each set of instruments ?

I would wait for the lab to decide what will happen to this chip. We should try to keep only platforms that exist in the lab in main, so if they warm up I would close all PRs. @alecandido @andrea-pasquale let us know if you agree.

Since this is a PR, I think it is possible to recover the state of the code at any point if needed by checking out the latest commit hash. This works even if the PR is closed and the branch is removed from GitHub.

As far as Fred told me they want to have another run next week on the same chip. Let's keep for next week and close it after it. Just wanted to know in case I needed to tidy the platform file or not.

[Jacfomg]

I agree that only the working platforms should be front and center in main. Maybe a good compromise is to have an "inactive" folder in main where we dump these platforms that could technically come back up. Also for ease of access of the platform files in order to build similar platforms in the future.

I could also store report as they will contain the parameters, not the platform though and some plots on how stuff should look like if we were to use that chip again. I would select some reports from this chip.

[Jacfomg]

Since in the end we did not repeat the benchmarks we can close this. I will create some issues for some of the things I found.