Updates for Qiskit to Braket circuit conversion

[kshitijc]

What is the expected behavior?

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Currently the convert_qiskit_to_braket_circuit function:

• Uses Probability result type for the Qiskit measure instruction: It might be better to use the Sample result type if you wish to retrieve the measurement values (the raw 0/1 values). Probability result type might in the future choose to omit the raw measurements.
• Doesn't support the barrier instruction: Look at verbatim support and see if this aligns with barrier.

[stigerasmussen]

Changing to sample would also add support for TN1, which does not support Probability results type: https://docs.aws.amazon.com/braket/latest/developerguide/braket-result-types.html

Suggested solution: change line 344 in adapter.py to: quantum_circuit.add_result_type( result_types.Sample(Observable.Z(), target=[ circuit.find_bit(qiskit_gates[1][0]).index, circuit.find_bit(qiskit_gates[2][0]).index, ] ) )

[dakk]

@kshitijc As far as I understand we cannot use verbatim to simulate a qiskit barrier beacuse:

• The verbatim feature would make sure that specific quantum gates are executed in the exact order they are specified, without any transformation or optimization.
• A barrier doesn't prevent transformations within its boundaries but rather stops optimizations or rearrangements of quantum operations across the barrier.

Maybe an empty verbatim box could do the trick?

[urihan]

Hello! I was working on the Support for Parametric Circuits #86, but someone else submitted the PR. So, I started working on this issue since it was closely related! I apologize for not asking before submitting a PR.

[kshitijc]

@dakk you're right. Let's remove the support for barrier instructions from the scope for this task.

[JordanAWS]

@urihan it looks like you submitted the PR for this issue, while @dakk provided help resolving ambiguities and scope. For the structure of unitaryHack, we can either assign an issue to a single person (where they get the full bounty) or assign it to multiple people, where they split the bounty evenly.

Are you two comfortable with a 50-50 split of the bounty?

[JordanAWS]

If not, since @urihan was the author of the PR, we would award them the bounty, and we could provide @dakk some AWS credits to use on Braket to compensate for their work.

Please let me know how the two of you would like to proceed, any strong feelings you have one way or the other. :)

[urihan]

Hi @JordanAWS, I don't mind splitting 50-50 bounty or giving all bounty to @dakk. I would instead prefer getting AWS credits on Braket because my goal was to get familiarized with Braket's open-source through this opportunity. How do you want to split this @dakk?

[dakk]

Hi, I didn't expected anything when I helped @urihan ! Anyway, if it is ok for @urihan and if it is possible, we can get both assigned for solving the issue (helping improving my qiskit advocate application score), while @urihan can get the full bounty for it (or whatever @urihan decides to do it is ok for me).

[urihan]

Hi @JordanAWS, is what @dakk recommended possible?

[dakk]

@JordanAWS or @kshitijc the UnitaryHack is closing, please reply to @urihan

[JordanAWS]

Sorry @urihan I missed your question. I am not sure how Qiskit advocate scores work, but I guess I added @dakk as an assigned contributor as well. I will tell the organizers that @urihan should receive the full bounty.

[dakk]

Thank you @JordanAWS 🙏