Braket circuit compilation method for `AwsDeviceWrapper.run`

ryanhill1 commented 1 year ago

Unitary Hack scope

Transpile an Amazon Braket circuit to a circuit composed of native gates for IonQ Harmony device.

Implement function similar to qiskit circuit transpiler for braket.circuits.Circuit type. For Unitary Hack submissions, successful implementation for IonQ Harmony device can close this issue and receive bounty! For further guidance and implementation tips, see below.

Here are some further details that may help!

AwsDevice supported gates

Example of getting supported gate set for IonQ device:

# import the device module
from braket.aws import AwsDevice

device = AwsDevice("arn:aws:braket:us-east-1::device/qpu/ionq/Harmony")

# get device name
device_name = device.name
# show supportedQuantumOperations (supported gates for a device)
device_operations = device.properties.dict()['action']['braket.ir.openqasm.program']['supportedOperations']
print('Quantum Gates supported by {}:\n {}'.format(device_name, device_operations))

Quantum Gates supported by the Harmony device:
 ['x', 'y', 'z', 'rx', 'ry', 'rz', 'h', 'cnot', 's', 'si', 't', 'ti', 'v', 'vi', 'xx', 'yy', 'zz', 'swap', 'i']

qBraid DeviceLikeWrapper runtime

In this issue, we implement a function/method that is called after _compat_run_input() and before AwsDevice.run() that checks that the Amazon Braket circuit being submitted is composed only of gates that are supported by the target device. For each wrapped AwsDevice, you can get the supported gate set as shown in the example code above.

Implementation brainstorm

There are a number of approaches that can be taken. Integration with third-party packages is not off the table, but we also want to keep the number of transpilations between different packages to a minimum, if we can, because each time we do one we have the potential of losing information about the circuit, and converting back always runs the risk of popping up new unsupported gates. That being said, here are some options:

The transpiler already supports conversions to/from pytket. So integrating with the pytket-extension(s) could be one approach.
Build a native Amazon Braket function modeled after the qiskit.compiler.transpiler function. Amazon Braket only has ~38 different gates total, and because you know the supported gate sets of each of the devices ahead of time, you may be able to take some shortcuts by solving the most common mappings first, and leverage the qiskit implementation for edge cases.
A third approach could be to leverage OpenQASM. Amazon Braket circuits can be converted to OpenQASM 3 strings, and that initial, automatic decomposition to the qasm gate set could be a strong first step. From there, you could leverage the qasm standard library to swap operations out programmatically, or simply parse the qasm code line-by-line.

There are many approaches, so pick whichever feels most logical.

ryanhill1 commented 1 year ago

rum1887 commented 1 year ago

hello @ryanhill1 , interested in taking up this issue

ryanhill1 commented 1 year ago

@rum1887 sounds great!

DarthRevan07 commented 1 year ago

@rum1887 Can i have a jibe at this too? I'm already made some progress... i figured that everyone could work on this, so i didn't ask to get assigned earlier. Could you assign it to me now?

ryanhill1 commented 1 year ago

@mmlouamri please comment so issue can be assigned to you to receive Unitary Hack project credit for #257

mmlouamri commented 1 year ago

Thank you! It was a great learning experience 🙏!

qBraid / qBraid