Retrieve old jobs #1099
Retrieve old jobs #1099
Conversation
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
| Raises: | ||
| ~gss.SuperstaqServerException: If there was an error accessing the API. | ||
| """ | ||
| job = self._client.fetch_jobs([job_id]) |
There was a problem hiding this comment.
this should also be able to multi-circuit jobs (via a comma-separated job_id), e.g.
| job = self._client.fetch_jobs([job_id]) | |
| jobs = self._client.fetch_jobs(job_id.split(",")) |
(and with the logic below updated accordingly)
in this case we'll also probably want to check that all the retrieved jobs have the same target, and if not throw an error
There was a problem hiding this comment.
We opted to fetch one job to match the implementation in cirq_superstaq. Should that also be able to retrieve multi-circuit jobs?
There was a problem hiding this comment.
css.Service.get_job() accepts comma-separated job ids - e.g. this works for me:
service = css.Service()
job = service.create_job(
[
cirq.Circuit(cirq.measure(cirq.q(0))),
cirq.Circuit(cirq.X(cirq.q(0)), cirq.measure(cirq.q(0)))
],
target="ss_unconstrained_simulator",
method="dry-run",
)
print(job.job_id()) # will have a comma, e.g. "bc58eb54-5787-4328-bd45-a53f0cd609c,66f63a82-822d-43f0-8c1d-dce1923ec67"
new_job = service.get_job(job.job_id())
print(new_job.counts(0)) # {"0": 1000}
print(new_job.counts(1)) # {"1": 1000}There was a problem hiding this comment.
My bad! I looked at the docstring for get_job() and it seemed like it only took a single job id.
def get_job(self, job_id: str) -> css.job.Job:
"""Gets a job that has been created on the Superstaq API.
Args:
job_id: The UUID of the job. Jobs are assigned these numbers by the server during the
creation of the job.
Returns:
A `css.Job` which can be queried for status or results.
Raises:
~gss.SuperstaqServerException: If there was an error accessing the API.
"""
return css.job.Job(client=self._client, job_id=job_id)There was a problem hiding this comment.
ah yeah that's confusing lol. i think the idea was that a job id with commas is still just a single "job id", but for a multi-circuit job?
There was a problem hiding this comment.
I think that makes sense.
are we sure we want to drop backend.retrieve_jobs? this is technically a breaking change (though not sure how much use it gets so maybe doesn't matter) |
I can try looking for instances of its use. The only one I found through test failures was in a notebook. @vtomole what do you think? |
|
From dev meeting: Add deprecation warning for usage and remove later. |
| @@ -164,6 +164,30 @@ def backends( | |||
| superstaq_backends.append(self.get_backend(backend.target)) | |||
| return superstaq_backends | |||
|
|
|||
| def retrieve_job(self, job_id: str) -> qss.SuperstaqJob: | |||
There was a problem hiding this comment.
Change to get_job for cirq-superstaq parity
| Raises: | ||
| ~gss.SuperstaqServerException: If there was an error accessing the API. | ||
| """ | ||
| warnings.warn( |
There was a problem hiding this comment.
Use Cirq's deprecation infrastructure. Here's an example
There was a problem hiding this comment.
Is it worth having our own deprecation warning decorator in gss?
There was a problem hiding this comment.
What version should we say is the deadline for deprecation?
There was a problem hiding this comment.
Double checking. This is the warning body we will have
f'{qualname} was used but is deprecated.\n' f'It will be removed in cirq {deadline}.\n' f'{fix}\n'.
Given that the message will state that the function will be deprecated for a certain cirq version, should we use it for qss?
There was a problem hiding this comment.
Ah I see. What we have now is fine then.
Addressing #727. For
qiskit_superstaq, this enables users to retrieve a job without specifying a backend using theqss.SuperstaqProviderobject.