Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support VQEClient.retrieve_job() #479

Closed
ikkoham opened this issue Dec 22, 2021 · 10 comments
Closed

Support VQEClient.retrieve_job() #479

ikkoham opened this issue Dec 22, 2021 · 10 comments
Assignees
Labels
mod: runtime Runtime Client related issues type: enhancement

Comments

@ikkoham
Copy link
Contributor

ikkoham commented Dec 22, 2021

What is the expected enhancement?

I want this method because I sometimes want to retrieve a runtime job later. Is there another way?

@HuangJunye
Copy link
Contributor

You can retrieve runtime jobs using the following code. See also: https://qiskit.org/documentation/partners/qiskit_runtime/tutorials/00_introduction.html It's retrieved on the provider level not backend level as it is done for normal circuit / Qobj jobs.

from qiskit import IBMQ
IBMQ.load_account()
provider = IBMQ.get_provider(hub='HUB_NAME', group='GROUP_NAME', project='PROJECT_NAME')
job = provider.runtime.job('JOB_ID')

But I agree that it would be a good idea to add VQEClient.retrieve_job() API.

@iuliazidaru
Copy link
Contributor

May I work on this issue?

@mrossinek
Copy link
Member

@iuliazidaru Sure thing! Maybe you can sync with @Cryoris who originally wrote the VQEClient 👍

@Cryoris
Copy link
Contributor

Cryoris commented Jan 20, 2022

We already store the job_id in the result you get back from the VQEClient, so retrieving the job would be as easy as doing

provider = ...
my_vqe = VQEClient(ansatz, ..., provider=provider)
my_result = my_vqe.compute_minimum_eigenvalue(...)

# retrieve job
job = provider.runtime.job(my_result.job_id)

Since we design our algorithms to be stateless we also wouldn't want to store the last job ID in the VQEClient. @ikkoham do you have a use-case in mind where calling something like

job = my_vqe.retrieve_job(my_result.job_id)  # or just my_result

would be more useful than just directly calling

job = provider.runtime.job(my_result.job_id)

?

@ikkoham
Copy link
Contributor Author

ikkoham commented Jan 26, 2022

@Cryoris Thanks. You are right. I certainly don't think that VQE.retrieve_job is necessary. What I really want is something that makes it easy to make a MinimumEigensolverResult from the job_id.

@Cryoris
Copy link
Contributor

Cryoris commented Jan 26, 2022

Ah I see! Yes I think this should be possible -- as long as the job result is still stored on our servers. From the job ID we can query both the result and the inputs which should enable us to construct the results object.

@iuliazidaru are you still interested in tackling this issue? 🙂

@iuliazidaru
Copy link
Contributor

@Cryoris Yes. I'll implement it.

@Cryoris
Copy link
Contributor

Cryoris commented Jan 28, 2022

Great 🙂 let me know if I can help you out!

Since it's not about the job but about the result I think we should call the function retrieve_result that takes a provider and a job_id and returns a VQEResult. You should be able to get the job associated with the job_id via

job = provider.runtime.job(job_id)

and then the properties of the VQEResult should be reconstructable from what's in job.inputs and job.result().

It might be good to make this function a staticmethod as it doesn't have anything to do with the algorithm setup, such as the ansatz or backend.

@ikkoham
Copy link
Contributor Author

ikkoham commented Jan 31, 2022

@Cryoris Thanks. It might be better to name the method differently.

@mrossinek
Copy link
Member

Closing this as per #1124

@mrossinek mrossinek closed this as not planned Won't fix, can't repro, duplicate, stale Apr 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mod: runtime Runtime Client related issues type: enhancement
Projects
None yet
Development

No branches or pull requests

5 participants