-
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
Remove qs2/3 references #78
Conversation
README.md
Outdated
@@ -194,10 +194,8 @@ print(device.run(bell, s3_folder).result().measurement_counts) | |||
The code sample imports the Amazon Braket framework, then defines the execution environment as the AWSQuantumSimulator and the device to use. The `s3_folder` statement defines the Amazon S3 bucket for job output and the folder in the bucket to store job output. This folder is created when you run the job. It then creates a Bell Pair circuit, executes the circuit on the simulator and prints the results of the job. | |||
|
|||
### Available Simulators | |||
There are currently three simulators available for Amazon Braket. To specify which simulator to use, change the code sample to replace the value for the `AwsQuantumSimulator` to one of the following values: | |||
There is currently one simulator available for Amazon Braket: |
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.
"one cloud simulator"?
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.
could it say one "Amazon Braket simulator" available? Or are you trying to differentiate from the local one? We don't really use "cloud" in AWS v. on AWS, and we have many cloud services CloudFormation, CloudTrail, CloudWatch etc.
Since the local one is part of the SDK and not part of the Braket service per se would that work?
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.
Yeah, that would be better. Changed.
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.
or say AWS simulator I guess since that it how it is referenced in code.
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.
Thanks. Changed to AwsQuantumSimulator.
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
@@ -252,7 +252,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 failing 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.
"this keeps the local task from failing before the task is run on the QPU." -> I think the task wouldn't fail. It would be the call to the .result() method which would return None.
Also the term local task might be confusing since there is a LocalQuantumTask class (used with LocalSimulator) which is different from the AwsQuantumTask class being used here.
The idea we want to convey is that the result() method on the AwsQuantumTask class polls the service to check if the task is in one of the terminal states (COMPLETE, FAILED, or CANCELLED) for poll_timeout_seconds
(which has a default value of 2 minutes) before retrieving the results from S3. For QPUs the results might not be ready within that time frame so we can have our code execute the polling for a longer period of time, such as 24 hours.
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.
Also, please move these changes to a separate PR so that we can commit them separately.
# Cherry pick changes onto new branch (docs_update)
git checkout -b feature/docs_update origin/master
git cherry-pick 215df9d0ca213b073fd90ff319be45c476e6bd7c
# Make changes to docs and git push to create the PR as per usual flow
# Remove these changes from this PR
git checkout feature/deprecate_qs3
git revert 215df9d0ca213b073fd90ff319be45c476e6bd7c
git push
This reverts commit 215df9d.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
build_files.tar.gz