Access to IonQ hardware via AWS account

[nonhermitian]

What feature would you like to see added? Why is it valuable?

Most users accessing the IonQ systems and simulators do not have a direct account with IonQ as the docs suggest for access: https://qiskit.org/documentation/partners/ionq/guides/access.html

Rather, it would be nice if support was provided for access via an users AWS account, a la:

https://github.com/carstenblank/qiskit-aws-braket-provider

What is the expected behavior, in detail?

Can you help make this feature a reality? By yourself? If not, what support would you need?

[ColemanCollins]

To keep the conversation moving on this, I do want/intend to do this, especially given there's prior art to help shape the interface, it's just a fairly large change and I'm strapped for time right now. I plan to return to it sometime in May when I have a bit more time, but happy for help from any contributors (or folks who want to become contributors!) willing to take a shot at it before then.

[berryboy2012]

Hi! I found this issue based on a discussion about current state of support for AWS Braket platform, and I would like to share some of my thoughts reiterated below:

As far as I know, frameworks provided by AWS braket is quite different from 'native' ones provided by QPU manufacturers, let alone lacking many essential features (for example transpiling a circuit and accepting circuits described in OpenQASM). On the other hand, AWS braket does provide a uniform access to different QPUs and simulators. To sum up, while it is nice to include AWS braket support in qiskit-ionq provider, I think it might be better to implement such functionality as a standalone module.

Speaking of bringing AWS braket support, I would like to contribute to such project, but I would like to understand current state of the situation so people won't be wasting time doing redundant work.

My main thoughts are that it makes more sense to implement a new qiskit-provider for QPUs/simulators provided by AWS Braket, and I would like to make some contributions, thanks!

For people who might be concerned, qconvert does provide a ready-to-use proof-of-concept tool converting OpenQASM to AWS Braket 'commands'.

[nonhermitian]

So yeah, there should probably be a different package of some kind that handles the execution logic. I would say though that from an user point of view it would be nice to have a singular way to access IONQ (or other) systems, i.e. the qiskit-ionq provider should provide the access. If accessing via AWS, then the IONQ provider would just call out to this new execution engine.

[amilstead]

... If accessing via AWS, then the IONQ provider would just call out to this new execution engine.

Couldn't agree more!

To be clear we are more than happy to implement a solution, so long as it is scoped to integrating an existing AWS Braket-specific library.

To @berryboy2012's point-- writing a qiskit provider-specific integration here seems less valuable than a distinct, standalone provider for Braket.

@berryboy2012, are you are interested in jump-starting a Braket provider or did you just want to contribute if possible?

[ColemanCollins]

potentially interesting update here: https://github.com/qiskit-community/qiskit-braket-provider