Support Qiskit 1.0

[natestemen]

Dependabot has opened a PR https://github.com/unitaryfund/mitiq/pull/2192, but it will need some help to get over the line.

https://github.com/unitaryfund/mitiq/pull/2207

[purva-thakre]

We might have to wait for qasm parser in cirq to be compatible with qiskit 1.0.

Linking an issue I created in cirq: https://github.com/quantumlib/Cirq/issues/6480

[andre-a-alves]

I will be nowhere near a computer for a couple weeks, but I spent a few hours taking a stab at this before going on vacation, and perhaps what I ran into will be helpful for the next person that wants to tackle this issue.

Many of the incompatibility issues are rather trivial to repair and just require simple changes to API calls resulting from Qiskit depreciating the execute() function. But mitiq/interface/mitiq_qiskit/conversions.py/_transform_registers() is where I ran into a much bigger problem. After going through the Qiskit code and adapting Mitiq's reassignments of the private Qiskit attributes, I was able to adjust the code so that it has the same behavior that it used to. However, Qiskit is no longer purely Python, and the error that gets raised is raised from within Rust. The Rust portion of Qiskit picks up on the fact that the registers have been altered, and the fact that the registers have been altered throws an error. Unfortunately, Qiskit does not currently have an API that allows registers to be changed (which is why private attributes were changed in the first place). It appears to me that the approach that is currently taken where the registers are cleared and replaced with new ones is incompatible with Qiskit 1.0+.

1422 may provide the best way forward.

If at the end of the month this has still not been solved, I can revisit it. But it appeared to me that this is where the biggest challenge comes from in supporting Qiskit 1.0+.

[purva-thakre]

If at the end of the month this has still not been solved, I can revisit it.

@andre-a-alves Go for it. I couldn't find the source of the error. Seems like you do!

If you look at the commits in #2207, most of the errors have been resolved except for the ones where I thought they might be related to the qasm parser in cirq.

Another set of errors is from pennylane being incompatible with this version of qiskit.

[nathanshammah]

@andre-a-alves thanks a lot for this! Do you have any recent updates? This seems to me like an important issue to prioritize, if needed working in team (with someone taking the lead). Cc @cosenal @jordandsullivan can also help.

[andre-a-alves]

@nathanshammah I am just starting to look into it now. Based on Qiskit's new architecture that includes splitting the code between Python and Rust, our old, low-level approach of changing the registers will not work. I think a transpiler plugin is probably the best approach, as mentioned in #1422. If anyone has experience with writing one, I would welcome the help.

Meanwhile, last month before I went on a long vacation, I had already started making several Qiskit updates such as replacing the old qiskit.execute() with the three-step process ending in backend.run(), updating imports, etc. In case anyone else is working on this at the same time and could benefit from what is already done, I will publish my current branch over the weekend and link it here.

[andre-a-alves]

As mentioned above, here is a branch that contains the changes I had made thus far. It's the starting point from which I am approaching this issue. For coordination purposes, I plan to first fix other Qiskit issues not related to _transform_registers(), and then I will get started working on the transpiler.

I don't plan to publish anymore to that branch - it just has one big commit to show changes I had made, but I would rather have an organized series of commits addressing atomic changes. It is shared for everyone's situational awareness.

[purva-thakre]

Commenting this for later: IBM is retiring all cloud simulators available here in May 2024.

A quick keyword search shows we are not using these but we should probably be aware in case someone runs into additional issues when they are using v1.0.

IBM's announcement: https://docs.quantum.ibm.com/announcements/product-updates/2024-03-22-announcement-cloud-simulators-and-lab#focus-on-utility-scale-computing-retirement-of-cloud-simulators-and-ibm-quantum-lab

[FarLab]

Hi @andre-a-alves, are you still planning to work on this issue?

[nathanshammah]

Great to see the PR @andre-a-alves! Adding a link to the migration guide in case it's helpful.