✨ Added free IBM hardware (kyiv, brisbane, sherbrooke) to CLI

[Drewniok]

This PR adds the free IBM quantum computers (kyiv, brisbane, sherbrooke) to the CLI of MQT-Bench.
We also provide a script that generates the calibration files (json) based on the calibration csv files downloaded from IBM.

[codecov]

Codecov Report

Attention: Patch coverage is 50.87719% with 56 lines in your changes missing coverage. Please review.

Project coverage is 91.2%. Comparing base (d24e61d) to head (566d470).

Files with missing lines	Patch %	Lines
src/mqt/bench/devices/ibm_open_access.py	50.0%	56 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #381     +/-   ##
=======================================
- Coverage   93.0%   91.2%   -1.9%     
=======================================
  Files         48      49      +1     
  Lines       2438    2551    +113     
=======================================
+ Hits        2269    2327     +58     
- Misses       169     224     +55     

Flag	Coverage Δ
python	91.2% <50.8%> (-1.9%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[burgholzer]

Thanks for working on this! 🙏🏼
Sorry that it took a while to review.
Most of the comments you'll find below are rather on the high-level side and are probably better translated to follow-up issues.
I think my biggest concern that should probably be addressed here is the amount of code duplication between the IBM providers.

[burgholzer]

This is more of a side note on the calibration files in general.
We seem to be missing timing information (how long a certain gate takes) for single-qubit gates in most (if not all) of the calibration files.
I believe the original IBM calibration files contain that kind of information.

(This could be converted to an issue to tackle separately)

[burgholzer]

Another high-level comment: At the moment, we are storing kind of proprietary calibration files here. And we store them differently for every provider. It would be great to unify that hardware description format for all the devices here. Which would also allow to share a lot of the code for parsing the calibration files.

(This could be converted to an issue to tackle separately)

[burgholzer]

This duplicates quite a lot of the code from the ibm provider. Do you see any way of unifying that to reduce this duplication. In essence, the only big difference between the regular ibm provider and the new one here is the native gate-set.
I feel it should be possible to unify the implementation a little bit here.

One possible idea in that regard would be to kind of refactor the device handling to remove the Provider concept and replace it with base classes of Devices that implement shared functionality.
This might take a little work, but I think in the this might be a little more scalable for the future.
In the mid-term (maybe earlier), a device should be described in a standardised fashion so there should really be no need to provide this Provider abstraction.
The list of supported gate-sets by MQT Bench (e.g., for the native gates level) is then simply the union of all the different gate sets provided by all available devices.

(Given the scope of this request, this might also be better tackled in a separate follow-up issue. However, at least some kind of de-duplication would be nice. Maybe that also helps with getting a bit better coverage)

[burgholzer]

We shouldn't be adding to the list of OpenQASM gates here, as, in fact, the ecr gate is not an OpenQASM 2 standard gate.
We handle a pretty similar case already for OQC devices (which also offer the ECR gate as their basis gate).
Any kind of handling of that gate in the newly added devices should, in a first stage, handle this similarly.

In the long run, we definitely want to get rid of that whole list of gates here and move towards dumping OpenQASM 3 programs instead of OpenQASM 2.
However, I'd rather tackle this in a separate issue and use the same kind of special handling for the ECR gate here as for the OQC devices.

[burgholzer]

I am not the biggest fan of adding random requirements.txt files throughout the repository for purposes like these. The "modern" way to incorporate such extra functionality would be to use dedicated "extra" dependencies in the pyproject.toml or to use https://peps.python.org/pep-0723 if it is really just dependencies for a script. See for example https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies
Given that this is a script that really doesn't need more than that, I would follow the above guide and turn this into inline metadata for the script.

Note that qiskit_ibm_runtime is a direct requirement of pytket_qiskit. So it would be directly available within mqt-bench. However, this one-off script makes much more sense in a separate directory as compared to in the package.

[burgholzer]

I'd have a slight preference for calling the containing folder scripts compared to utils. Really not a big fan of the term utils 🙃

[Drewniok]

Thanks for working on this! 🙏🏼 Sorry that it took a while to review. Most of the comments you'll find below are rather on the high-level side and are probably better translated to follow-up issues. I think my biggest concern that should probably be addressed here is the amount of code duplication between the IBM providers.

Many thanks @burgholzer for your review! That's super helpful! And I totally agree about the code duplication! I'll address that asap.