-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECR Gate Compatibility #440
Comments
I'm popping in to note that I'd also find ECR compatibility helpful, as someone else working with IBM's devices currently. I haven't thought about the best approach, but I'll note that if we decide to convert to Qiskit circuits we need to be careful to control how those circuits get transpiled by Qiskit before running (so that they don't get optimized/compiled in unintended ways). |
Question for you coming from my position of relative ignorance on the IBM integration code: Any idea if this is an 'us' problem or a 'them' problem? I.e. is this a bug in our code, or something we should be reporting on one of IBM's repos? Edit: When you say Runtime the second time, do you mean when using the python API? |
I would say that it's an IBM/QASM suboptimality that is unlikely to be fixed and we are forced to accommodate. QASM does not directly allow a native ECR gate, i.e. writing ecr q[0], q[1]; and having that compile to an ECR gate on qubits 0 and 1. IBM has attempted to work around this by defining its method for converting Qiskit circuits to QASM a macro: gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(param0) q1; cx q0,q1; h q1; } We currently convert PyGSTi circuits to QASM to Qiskit circuits (to avoid more than minimal compilation). If we:
We get an error that the gate we implemented is not valid (I can't remember the exact error code--it's been a few months). If we run via pasting the QASM circuit into the IBM Quantum Composer it works. This shows how unstable the macro is (which also can be observed from the fact that none of the parameters or specifics defined in it matter). We talked to some folks from IBM about this at March Meeting and it doesn't seem to be a priority to fix. PS: The second instance was a typo and has been corrected. It was intended to read backend.run(). |
Is this guidance on constructing this macro from their documentation? Or is this what is returned when using the built in Qiskit function (Here) for dumping a QuantumCircuit object to either OpenQASM 2 or 3? I.e. if you construct a Qiskit circuit with an ECR gate, is this macro what is returned in the QASM by their own functions? |
@coreyostrove Using the Qiskit function to dump to QASM 2 from an ECR-containing circuit. There's no particular guidance available on how to interface QASM and ECR gates from IBM. |
Got it, one last question for you in that case (apologies for the inundation): What happens when you instead use QASM 3? Based on what you've described, it sounds like the following sequence of operations would result in an error:
If we find that step 2 succeeds while step 5 fails then this indeed sounds like it is an IBM problem (they should be able to handle the round trip in their serialization/deserialization, though I am empathetic to how tricky that is sometimes). As for how we would work around this, I'm not sure. If the use of macros is the problem, then maybe we could inline it? |
@coreyostrove I don't believe QASM 3 would fix the problem, but worth investigating. I believe the sequence of operations would result in an error. I'll put running through that sequence for both QASM 2 and QASM 3 on my to-do list and get back to you in a couple days with the results and a test notebook. The current thought for a workaround is to just convert pyGSTi circuits to Qiskit circuits without the QASM intermediary. The downsides are that that would take some time to implement and we would have to be very careful to avoid excessive transpilation as @jordanh6 pointed out above. |
I'll also note that Qiskit 1.0 has QASM 3 (experimental) support. So an interface to Qiskit circuit directly could also give us QASM 3 support "for free", modulo all the issues that direct interface would have... I just bring it up since QASM 3 is something we've also been thinking about, and we'll probably only have time to implement QASM 3 or Qiskit and it would be nice if we got the other as a result. |
Hmm. That's an interesting point. I'm currently a little worried that Qiskit 1.0 might torpedo QASM 2.0 support inadvertently as the qasm2 convertor seems to live in the unfortunate qiskit-terra package. From https://docs.quantum.ibm.com/api/qiskit/qasm2: "The parser components of this module started off as a separate PyPI package: qiskit-qasm2(opens in a new tab). This package at version 0.5.3 was vendored into Qiskit Terra 0.24. Any subsequent changes between the two packages may not necessarily be kept in sync. There is a newer version of the OpenQASM specification, version 3.0, which is described at https://openqasm.com(opens in a new tab). This includes far more facilities for high-level classical programming. Qiskit has some rudimentary support for OpenQASM 3 already; see qiskit.qasm3 for that. OpenQASM 2 is not a suitable serialization language for Qiskit’s QuantumCircuit. This module is provided for interoperability purposes, not as a general serialization format. If that is what you need, consider using qiskit.qpy instead." |
@coreyostrove I ran:
All five of these circuits ran successfully. I believe something must have been patched since I last worked on this issue, since I remember running into issues on 2 and 5 (I did not test 3-4). |
Huzzah! While it sucks when stuff is broken, it is always nice when we aren't the ones who need to fix it. Since you said you were able to successfully modify the |
Any of those solutions work for me, just let me know what you and @sserita would like to do. It's about a four line fix. Add the macro in the convert_to_qasm function and then add the ECR gate in internal gates. |
Fix comes from Piper. Should fix #440.
Is your feature request related to a problem? Please describe.
Current code for interfacing with IBM devices is not compatible with the ECR gate. However, all but one of the available IBM devices uses the ECR gate.
Describe the solution you'd like
I believe we should refactor the IBM code to convert directly from pyGSTi circuits to Qiskit circuits, as this would smoothly integrate the ECR gate.
Describe alternatives you've considered
I've considered trying to convert ECR gates to OpenQASM 2.0 as we currently do. However, this leads to very fragile QASM code:
OPENQASM 2.0;
include "qelib1.inc";
gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(param0) q1; cx q0,q1; h q1; }
gate ecr q0,q1 { rzx(pi/4) q0,q1; x q0; rzx(-pi/4) q0,q1; }
qreg q[3];
creg c[1];
ecr q[1],q[2];
ecr q[0],q[2];
measure q[2] -> c[0];
barrier q[0],q[1],q[2];
This works for jobs submitted through Runtime or the Quantum Composer on the IBM website, but seems to fail for jobs submitted through backend.run():
I'm concerned that if we pursue this avenue that the fix would be unstable.
The text was updated successfully, but these errors were encountered: