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

Remove qs2/3 references #78

Merged
merged 7 commits into from
May 19, 2020
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor Author

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.

Copy link
Contributor Author

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

```python
import boto3
from braket.circuits import Circuit
Expand All @@ -264,7 +264,8 @@ device = AwsQpu(AwsQpuArns.RIGETTI)
s3_folder = (f"braket-output-{aws_account_id}", "RIGETTI")

bell = Circuit().h(0).cnot(0, 1)
print(device.run(bell, s3_folder).result().measurement_counts)
print(device.run(bell, s3_folder),
poll_timeout_seconds=86400).result().measurement_counts)
```

Specify which quantum computer hardware to use by changing the value of the `device_arn` to the value for quantum computer to use:
Expand Down