-
Notifications
You must be signed in to change notification settings - Fork 118
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
Updates to README to add poll_timeout_seconds #79
Conversation
Updated the example algorithm to include poll_timeout_seconds, which lets you increase the default polling time to avoid local timeout errors when QPUs are not immediately available to run a task.
README.md
Outdated
@@ -254,7 +254,7 @@ Tasks sent to QPUs don't always run right away. For IonQ, jobs are run once ever | |||
## Running a Quantum Algorithm on a Quantum Computer | |||
With Amazon Braket, you can run your quantum circuit on a physical quantum computer. The steps to do so are the same as those described to validate your environment. Just replace the example code provided in this document with your own code. | |||
|
|||
The following example executes the same Bell Pair example described to validate your configuration against a Rigetti quantum computer. | |||
The following example executes the same Bell Pair example described to validate your configuration against a Rigetti quantum computer. For the case when the specified QPU is unavailable and tasks are not immediately run, a `poll_timeout_seconds` parameter is included to set a longer polling time. With this parameter, the results are not returned until the task reaches a status of COMPLETE, FAILED, or CANCELLED, or 24 hours passes. When using the default polling time, local timeout errors occur in some cases while waiting for the QPU to process the task. This example sets the polling time to one day (24 hours). Since tasks typically run within 24 hours this keeps the local task from timing out before the task is run on the QPU. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"For the case when the specified QPU is unavailable and tasks are not immediately run, a poll_timeout_seconds
parameter is included" -> Could this cause the users to think that there are specific cases they need to know about when the poll_timeout_seconds needs to be supplied ?
Would it be better to say that the simulator/QPUs might not return results immediately and we might need to poll for the results longer. This behavior can be tuned using the poll_timeout_seconds parameter. We poll for results until either the task finishes execution (which can either be successful or unsuccessful) or the poll timeout seconds period has elapsed. This example sets the polling time to one day .....
* Update README example to use poll_timeout_seconds Updated the example algorithm to include poll_timeout_seconds, which lets you increase the default polling time to avoid local timeout errors when QPUs are not immediately available to run a task. * Update to README to correct the description for poll_timout * Update README description of polling_timeout_seconds
* Update README example to use poll_timeout_seconds Updated the example algorithm to include poll_timeout_seconds, which lets you increase the default polling time to avoid local timeout errors when QPUs are not immediately available to run a task. * Update to README to correct the description for poll_timout * Update README description of polling_timeout_seconds
Issue #, if available:
Description of changes:
Update to README to include poll_timeout_seconds in the example to run an algorithm on a QPU.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.