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

WIP: add the Rigetti Forest API as a backend #250

Open
wants to merge 6 commits into
base: develop
from

Conversation

Projects
None yet
3 participants
@mapmeld
Copy link

mapmeld commented Jul 29, 2018

Hi - this is still a work in progress, but I wanted to share it with the ProjectQ team now in case you have concerns or comments

I want to make ProjectQ more portable / universal by adding the Rigetti / Forest API as a backend

Rigetti has an assembly-like language for quantum computers (Quil) similar to QASM, a QVM (quantum virtual machine), and limited access to real quantum processors... so in many ways it is similar to IBM's offering. In 2017 I created a "jsQuil" module to create and run quantum programs from a Node.js environment. This would be a similar setup and you can see how I've started to make that work here

My next steps would be to check that implementation details are correct (which gates are and aren't allowed). Also I am a little uncertain of the equivalent of IBM5QubitMapper.

@thomashaener

This comment has been minimized.

Copy link
Member

thomashaener commented Jul 30, 2018

Hi @mapmeld and thanks for starting to work on this!

I think it would be great to have more openly accessible hardware backends in ProjectQ. We were going to interface to Rigetti's chip a while back, but the terms for getting an API key were way too restrictive. I will check if these have changed in the meantime and if so, this would be a great contribution!

Concerning the mapping: The qubits of the 8-qubit chip seem to be arranged in a circle, so you can simply use the 1D chain mapper with periodic b.c. For the larger chip, one could implement a general mapper for arbitrary connectivity graphs with some (simple) heuristic, or just rely on the user to perform the mapping via a ManualMapper engine.

@mapmeld

This comment has been minimized.

Copy link
Author

mapmeld commented Aug 1, 2018

@thomashaener I am emailing with the Rigetti team now - once I have the API tested out on QVM jobs, they can schedule some time for me to test that it works with the real "QPU" devices, too

This is my first time reading this concept of mapping qubits, so I don't understand exactly. From the linear mapper example, it looks like... it depends how qubits are physically arranged because only nearby qubits can be connected through a quantum logic gate. That makes sense but I don't have insider knowledge. Is this something where it's easy to inherit from linear mapper, or that I should ask their team for advice on?

@thomashaener

This comment has been minimized.

Copy link
Member

thomashaener commented Aug 2, 2018

Sounds good, thanks!

Yes, you can just use the linear mapper. When implementing an algorithm, you don't have to worry about the connectivity of the hardware. You can assume all-to-all connectivity and the compiler then takes care of mapping the circuit to the connectivity graph of the underlying hardware. This includes swapping a qubit around in order to make it adjacent to another qubit which it is supposed to interact with via, e.g., a CNOT.
We currently have 2 mappers in ProjectQ which do this; one for linear chains (which you can use here for the 8-qubit chip), and one for a 2D grid. You don't need any insider knowledge, you simply have to add a LinearMapper to your compiler engine list, which then looks similar to the list at https://github.com/ProjectQ-Framework/ProjectQ/blob/develop/projectq/setups/linear.py#L155

@mapmeld

This comment has been minimized.

Copy link
Author

mapmeld commented Aug 4, 2018

I got some programs running on Rigetti's QVM and returned results from the async job!

Gate compatibility issues (this may be me not knowing different names for the same gates, or different ideas of what counts as 1 or 2 gates)

Gates which ProjectQ/IBM have, but I had questions on:

[edit: resolved] Quil PHASE = ProjectQ's Phase-shift (R) 
Rx, Ry, Rz... I currently call Rx(0.25) and output 'RX(pi/4)' in Quil.
- If I call Rx(-0.25), I get angle 0.0811927499838429, why?
Tdag (Tdagger) and Sdag as inverse of T and S - I don't know how to represent this, NOT T ?

Gates which Rigetti/Forest/Quil has, but I didn't see their match here:

I gate ("identity")
CZ ("controlled Z")
CNOT, CCNOT, CPHASE, CPHASE00, CPHASE01, CPHASE10
CSWAP, ISWAP, PSWAP

Plus classical programming which I'll read up on with ProjectQ:

Wait, reset, NOP, HALT
Classical TRUE / FALSE, NOT, AND, OR, MOVE, EXCHANGE
@thomashaener

This comment has been minimized.

Copy link
Member

thomashaener commented Aug 5, 2018

You can check the matrix of our gates to compare. Most of them are in https://github.com/ProjectQ-Framework/ProjectQ/blob/develop/projectq/ops/_gates.py
Ph is a global phase, so it's most-likely not what you are looking for.
projectq.ops.Rx does not have a math.pi in its definition.
What do you mean by

If I call Rx(-0.25), I get angle 0.0811927499838429, why?

Which Rx are you calling, and how do you get the angle?

To invert gates, you can do from projectq.ops import get_inverse and then, e.g., get_inverse(Rx(-0.25)) | qubit.

CZ is in projectq.ops, just make sure you have the newest version of projectq. In older versions, you could do from projectq.ops import C and C(Z) | (cqubit, target_qubit). CNOT and Toffoli can also be found in projectq.ops: from projectq.ops import Toffoli, CNOT. CSWAP is C(Swap), where Swap can be imported from projectq.ops.
If you have the gate matrices of the remaining gates, feel free to add new gates, it's really simple.

As a general note: In ProjectQ, controlled gates are represented as gates with additional control qubits; so when your backend gets a command cmd which describes a CNOT, then cmd.gate == X but the list of control qubits cmd.control_qubits will have length 1 and contain the control qubit. cmd.qubits is a tuple of quantum registers. For the CNOT, the tuple will have 1 quantum register of length 1 (the target qubit).

I would focus on the quantum instructions for now. We can then still add classical gates once everything works with quantum-only. Our reset would just be deallocation followed by a new allocation. Classical NOT = Quantum NOT applied to classical bit (=qubit which has been measured). But I would do this part in a second iteration.

@mapmeld mapmeld force-pushed the mapmeld:rigetti_forest branch from 105b6f8 to 710bd83 Dec 6, 2018

@mapmeld mapmeld force-pushed the mapmeld:rigetti_forest branch from 710bd83 to 587d9a6 Dec 6, 2018

@mapmeld

This comment has been minimized.

Copy link
Author

mapmeld commented Dec 6, 2018

Long time without me updating this! I got in sync with the latest develop branch, then made some changes to get Controlled gates, SWAP, Phase, and the Sdag and Tdag gates all working here.

I plan to change the tests and mock API responses in the next week

@ryansk10

This comment has been minimized.

Copy link

ryansk10 commented Jan 11, 2019

Hi @mapmeld - saw your recent activity here, and wanted to chime in on behalf of Rigetti. In particular, I wanted to note that we're moving away from the http endpoint in favor of a new message spec called rpcq, which you can find here https://github.com/rigetti/rpcq. Please let us know if there's anything we can do to help- hopefully it should be easier to work with.

@thomashaener thanks for your feedback about the terms of service. We updated them in October, in part as a result of to the feedback you shared with me last summer. Let me know if you think the terms are still too stringent!

(cc @mpharrigan)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.