Replies: 2 comments 1 reply
-
User might need different backends in whatever configuration possible. We already tried to force backend option in previous iteration with qiskit runtime programs. It didn't worked out :) What we want is to do something like (which will remove boilerplate code entirely) @distribute_task(target={"qubits": 5})
def my_quantum_task(**kwargs):
backend = kwarge.get("backend")
session = kwarge.get("session")
... But even this is still questionable. What we found is keeping things simple and explicit makes experience better. E.g if user passes backend let him handle backend. And we also want users to get used to primitives interface. It's just settling in. |
Beta Was this translation helpful? Give feedback.
-
Agree with @IceKhan13 . I have found that letting the user set things up (primitives, backends, etc.) is much easier than trying to manage them, and it is also more clear to the user. Win/Win |
Beta Was this translation helpful? Give feedback.
-
As a user, I might like to be able to specify the quantum backend I wish to run my program on as a parameter in either the Program or the Provider. That way, I wouldn't have to code that up myself, but could just specify I wish to run on
Location X
and "Quantum Serverless" would provision the backend for me automatically.Here's one way this might be done:
Another option might be to add the backend when calling the Provider's
run()
function, i.e.As far as implementing something like this, we could possibly use something along these lines: https://github.com/Qiskit-Extensions/quantum-serverless/blob/97caeb6a09b116a2b5e58bb376f2eb93d084f567/docs/development/examples/source_files/vqe/vqe.py#L127-L138
Though that code snippet creates a session, which maybe also would want to do (?)... anyway, the goal here would be remove the need for users to write boilerplate code / simply the user experience for running middleware programs.
@IceKhan13 @Tansito @caleb-johnson Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions