search

qiskit-community / qiskit-ionq

Qiskit provider for IonQ backends
https://qiskit-community.github.io/qiskit-ionq/
Apache License 2.0
42 stars 24 forks source link

Access to IonQ hardware via AWS account #62

Open nonhermitian opened 3 years ago

nonhermitian commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

... 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 commented 2 years ago

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