advanced IBMQBackend.jobs() filtering by ewinston · Pull Request #585 · Qiskit/qiskit

ewinston · 2018-06-20T21:24:20Z

Summary

Enable more advanced filtering when getting past jobs from IBM Q backends.

Details and comments

To get the last 5 jobs with errors:
job_list = backend.jobs(limit=5, status='ERROR')

To get the last 5 jobs with 1024 shots and counts of 00 and 11 exceeding 400,

job_list = backend.jobs(limit=5, filter={'backend.name'='ibmq_qasm_simulator, 'shots': 1024,
                                         'qasms.result.data.counts.00': {'gt': 400},
                                         'qasms.result.data.counts.11': {'gt': 400}})

To get jobs from 30 days ago,

past_day_30 = datetime.datetime.now() - datetime.timedelta(days=30)
my_filter = {'creationDate': {'lt': past_day_30.isoformat()}}
job_list = backend.jobs(limit=5, filter=my_filter)

ajavadia · 2018-06-21T00:12:14Z

I think we forgot to update the CHANGELOG in #501.. can you do it here, since they touch the same feature?

Previously when using the filter keyword it would return jobs from any backend satisfying the filter.

ewinston · 2018-06-21T19:20:12Z

@ajavadia I updated the CHANGELOG.

atilag

Thanks Erick! We have simplified a lot this functionality, and seems good overall... I've just left some comments that will probably need to be addressed before merging.

atilag · 2018-06-28T16:18:23Z

            list(IBMQJob): list of IBMQJob instances
+
+        Raises:
+            ValueError: status keyword value unrecognized


Throwing ValueError in this case gives a lot semantic meaning, which could be very useful for our user's code, this is great, but in order to keep the policy of everything thrown from QISKit should inherit from QISKitError, I'd suggest adding even more semantic meaning by creating a new exception class here that inherits from ValueError and IBMQBackendError:

IBMQBackendValueError(IBMQBackendError, ValueError): """ Value errors thrown within IBMQBackend """ pass

This way, user's code could capture exceptions by ValueError or QISKitError.

sounds good

atilag · 2018-06-28T16:21:43Z

+            if status == JobStatus.RUNNING:
+                this_filter = {'status': 'RUNNING',
+                               'infoQueue': {'exists': False}}
+                api_filter = {**api_filter, **this_filter}


Just a simple suggestion, I found this code clearer:

api_filter.update( this_filter )

What do you think?

sounds good

atilag · 2018-06-28T16:23:30Z

+                               'infoQueue.status': 'PENDING_IN_QUEUE'}
+                api_filter = {**api_filter, **this_filter}
+            elif status == JobStatus.CANCELLED:
+                this_filter = {'status': 'CANCELLED'}


This this_filter is not used anywhere.

atilag · 2018-06-28T16:24:02Z

+            elif status == JobStatus.CANCELLED:
+                this_filter = {'status': 'CANCELLED'}
+            elif status == JobStatus.DONE:
+                this_filter = {'status': 'COMPLETED'}


Same as above, this is not used anywhere.

atilag · 2018-06-28T16:24:18Z

+            elif status == JobStatus.DONE:
+                this_filter = {'status': 'COMPLETED'}
+            elif status == JobStatus.ERROR:
+                this_filter = {'status': {'regexp': '^ERROR'}}


... and same as above, this is not used anywhere.

atilag · 2018-06-28T16:24:58Z

+            elif status == JobStatus.ERROR:
+                this_filter = {'status': {'regexp': '^ERROR'}}
+            else:
+                raise ValueError('unrecongized value for "status" keyword '


Maybe raising: IBMQBackendValueError('...')?

atilag · 2018-06-28T16:39:56Z

+            self.log.info('match #%d: %s', i, job.result()._result['status'])
+            self.assertTrue(job.status['status'] == JobStatus.DONE)
+
+    def test_get_jobs_filter_counts(self):


What about first sending the jobs before testing them? I'm only worried about what happens if there's no such jobs in the server, so the test always passes and is not testing anything. (... maybe am I being to much skeptical? :))

I agree. I think I did this because of the trouble with assuring a job status for testing. It's a good argument for mocking the server.

* Implement advanced backend.jobs() filtering

ewinston requested review from ajavadia, atilag, delapuente and diego-plan9 as code owners June 20, 2018 21:24

ewinston force-pushed the job_filter branch from e8e39be to 1cc3091 Compare June 20, 2018 21:53

ewinston added 3 commits June 21, 2018 12:59

implement advanced backend.jobs() filtering

f7d0409

enforce backend_name in backend.jobs filter.

0c92e7e

Previously when using the filter keyword it would return jobs from any backend satisfying the filter.

minor commit

ca1eb36

ewinston force-pushed the job_filter branch from 3babdb1 to ca1eb36 Compare June 21, 2018 17:33

ewinston added 2 commits June 21, 2018 13:54

linting and style

67d19ac

small typo

0017ab6

ewinston added 2 commits June 25, 2018 14:43

Merge branch 'master' into job_filter

1fc368d

Merge branch 'master' into job_filter

381c6c2

atilag reviewed Jun 28, 2018

View reviewed changes

ewinston added 3 commits June 28, 2018 17:03

incorporating comments from @atilag

f6b82cc

Merge branch 'adv_job_filter' into job_filter

afbe80c

Merge branch 'master' into job_filter

26cc808

ewinston changed the title ~~[WIP] advanced IBMQBackend.jobs() filtering~~ advanced IBMQBackend.jobs() filtering Jun 28, 2018

ewinston and others added 3 commits June 28, 2018 19:16

change to least_busy

f957804

minor style change

75d4fa2

Raising IBMQBackendValueError instead of ValueError

97ba015

atilag approved these changes Jun 28, 2018

View reviewed changes

atilag merged commit 61392d7 into Qiskit:master Jun 29, 2018

lia-approves pushed a commit to edasgupta/qiskit-terra that referenced this pull request Jul 30, 2019

Advanced IBMQBackend.jobs() filtering (Qiskit#585)

f12604d

* Implement advanced backend.jobs() filtering

ewinston deleted the job_filter branch April 6, 2021 16:27

Conversation

ewinston commented Jun 20, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details and comments

Uh oh!

ajavadia commented Jun 21, 2018

Uh oh!

ewinston commented Jun 21, 2018

Uh oh!

atilag left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ewinston commented Jun 20, 2018 •

edited

Loading