Skip to content
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

QASM2.0 is not preserved by QuilC #823

Open
pranavm1502 opened this issue May 27, 2022 · 5 comments
Open

QASM2.0 is not preserved by QuilC #823

pranavm1502 opened this issue May 27, 2022 · 5 comments

Comments

@pranavm1502
Copy link

Issue Description

Converting a QASM2.0 circuit to native_quil does the not preserve the circuit. There are two obvious errors-

  1. It adds extraneous single qubit and multi-qubit gates
  2. It removed the Barrier on the three qubits before measuring.

Code Snippet

new_qasm = """OPENQASM 2.0;
include "qelib1.inc";
qreg q[80];
creg c[2];
cz q[25],q[24];
cz q[23],q[24];
barrier q[25],q[23],q[24];
measure q[25] -> c[0];
measure q[23] -> c[1];
"""
program = pyquil.Program(RawInstr(new_qasm)).wrap_in_numshots_loop(shots)
qc.compiler.quil_to_native_quil(program).instructions

Error Output

[<DECLARE c>,
 <Gate CZ 25 24>,
 <Gate RZ(pi/2) 23>,
 <Gate RZ(pi) 24>,
 <Gate RX(pi/2) 24>,
 <Gate RZ(pi/2) 24>,
 <Gate RX(-pi/2) 24>,
 <Gate RZ(-pi) 24>,
 <Gate XY(pi) 23 24>,
 <Gate RX(pi/2) 23>,
 <Gate RZ(-pi/2) 23>,
 <Gate RX(-pi/2) 23>,
 <Gate XY(pi) 23 24>,
 <Gate RZ(-pi) 24>,
 <Gate RX(pi/2) 24>,
 <Gate RZ(pi/2) 24>,
 <Gate RX(-pi/2) 24>,
 <Gate RZ(-pi/2) 24>,
 <pyquil.quilbase.Measurement at 0x7f3ab82be650>,
 <pyquil.quilbase.Measurement at 0x7f3ab82be770>]

Environment Context

I am running this code on the QCS server.

This issue has also been filed at the pyquil repo -
rigetti/pyquil#1445

@pranavm1502 pranavm1502 changed the title QASM2.0 is not preserved by QASM2.0 is not preserved by QuilC May 27, 2022
@stylewarning
Copy link
Member

Hello @pranavm1502! The output does not look unexpected to me; it took the QASM program and compiled it for a Rigetti architecture with an XY gate. If you want to compile for a specific quantum computer architecture, you need to construct and supply a QuantumComputer object.

The qubits the program is operating on are not extraneous either. The compiler chose qubits it thought would be better for the calculation.

Could you describe more to me what output you're aiming to get? It's probably a matter of configuring options.

@stylewarning
Copy link
Member

(I should also add: The fact the input has 2 CZ gates and the output has 1 CZ + 2 XY is not good; there's no good reason for that, probably, and that ought to be investigated and fixed.)

@pranavm1502
Copy link
Author

Hi @stylewarning ! This code is being compiled for a specific Rigetti backend Aspen-M-1. The backend calibrations show the existence of a CZ gate for both the qubit pairs [24,23] and [24,25]. Naively I would expect the compiler to leave the circuit untouched since it is the shortest circuit of native gates.

Now it's possible that the compiler pulled in information about backend gate errors and determined that 2XY is better than 1CZ for that specific qubit pair ( Fid_XY = 97.83% ± 0.32% | Fidelity_CZ = 88.52% ± 1.04%). This is a fair behaviour. However, I would like to be able to disable such "noise-aware" compilation. Any ideas how to do that?

@stylewarning
Copy link
Member

My immediate suggestion is to modify the QuantumComputer object to not have fidelity information, or at the very least, make the fidelities ideal. At present, I'm not aware of an option to say "here are fidelities, but ignore them", but it wouldn't be too hard to push that feature out if the developers thought it was a broadly useful idea.

It would also be possible to write a function in Python to take a QC object and strip it of that metadata. Do you think you could try that first? (Sorry, I'd try it for you but I'm away from my dev computer for now.)

@pranavm1502
Copy link
Author

Thanks! Sounds good. Pyquil 3 doesn't seem to allow a method to change the ISA for QuantumComputer. I will look more into this next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants