Error when getting result from Rigetti

Thanks for reaching out! In order to help us investigate this issue, could you please provide the task IDs for which you're not able to retrieve any results ?

Sure. Here is a particular which gives the described error.

task_id3='arn:aws:braket:us-west-1:277893446508:quantum-task/9a50742f-bfc9-4575-b039-f7ef070e8f58'
task_load = AwsQuantumTask(arn=task_id3)
task_load.result()

I can give more ids as well but they all produce the same error.

Thanks, this corrected the error message. After updating the relevant packages, I was able to recover the results which were previously inaccessible. However, when attempting to retrieve some results, I now notice the kernel hangs while processing the task.result() command. This seemed to perhaps coincide with the "availability window" that Rigetti has. Is this the case? Can I only pull results for previously run jobs during the Rigetti availability times or is something else happening here?

Here is another test job result id if it is needed:
'arn:aws:braket:us-west-1:277893446508:quantum-task/622f56a1-60b2-4490-a105-2a4401803e8b'

You are correct, this is currently the behavior of the SDK. However, it is not the intended behavior. We are working to fix this so that you will be able to get the results outside the Rigetti availability window. In the meantime, you could try manually downloading results from the S3 bucket you specified when starting the task. Also, I’ve provided some Braket SDK code links below that you might be able to use for a temporary workaround.

This method is where the SDK implements downloading the results using Boto:
https://github.com/aws/amazon-braket-sdk-python/blob/d0a938f33004c03eee6307d131bf004aa5252f9f/src/braket/aws/aws_session.py#L97

Here is where the SDK uses that method to parse the results:
https://github.com/aws/amazon-braket-sdk-python/blob/d0a938f33004c03eee6307d131bf004aa5252f9f/src/braket/aws/aws_quantum_task.py#L365

Lastly, you would want to use something like this version of the _format_result function:
https://github.com/aws/amazon-braket-sdk-python/blob/d0a938f33004c03eee6307d131bf004aa5252f9f/src/braket/aws/aws_quantum_task.py#L529

Ok, thanks for clarifying this.

There is however an additional issue which is somewhat related to the original programDuration=0.0 bug.

This programDuration was encountered because I ran some randomized benchmarking circuits on Rigetti . I looked at the metadata for these circuits and it lists properties of (id tag for reference: 'arn:aws:braket:us-west-1:277893446508:quantum-task/0ed42428-2a7e-46cc-8a5a-2dde40d20c77'):

gateDepth=0, gateVolume=0, multiQubitGateDepth=0, programDuration=0.0, programFidelity=1.0, qpuRuntimeEstimation=181.88999938964844, topologicalSwaps=0

Even though the circuit itself is listed as:

[I(target=0, type=<Type.i: 'i'>),
I(target=1, type=<Type.i: 'i'>),
Y(target=1, type=<Type.y: 'y'>),
Z(target=0, type=<Type.z: 'z'>),
Z(target=0, type=<Type.z: 'z'>),
Y(target=1, type=<Type.y: 'y'>)]

From this, I would guess that after I submit the circuit, some automatic compilation takes place and simplifies the circuit to the Identity (which it is mathematically). However, I do not want this circuit simplified in this way. Is my assumption correct that some compilation step has taken place? If so, can I prevent it somehow?

Edited by: bgard on Jan 6, 2021 11:50 AM

You are correct. There is an optimization step that is reducing the circuit to the identity. We do not currently have a flag or option to skip optimization.

Is it possible that this option will be added in the future?

Currently this makes running certain benchmarking circuits on the Rigetti device, very difficult.

Additionally, the compiliation step selects qubits based on the circuit it runs. For example, if a circuit contains no two qubit gates, it seems to select the qubits with the 'best' single qubit gate fidelities. If a two qubit gate is present, it selects (generally different) qubits that have the 'best' two qubit fidelities. This also makes benchmarking a set of qubits difficult since the user does not have control over the exact qubits used. It seems there is also a bug with this implementation. On Jan 8th, the qubits 3 and 4 on Rigetti's Aspen-8 report an 'fXY' fidelity of '-1' ,which I presume to mean that this pair of qubits have very poor XY gates on this day (the results were very bad in this case). However, the compilation step actually selected these qubits to perform two qubit gates, likely thinking that '-1' is a good fidelity.

Ideally, it would be nice to select the physical qubits which are used for a given circuit (if desired) as well as if the optimization of the circuit is performed.

Edited by: bgard on Jan 12, 2021 8:31 AM

Edited by: bgard on Jan 12, 2021 8:37 AM

As a general rule, we don't comment on the future direction of the service, but we much appreciate these details of your use case.

Hi bgard,

It is already possible to determine qubit allocation manually on Rigetti devices, see for instance https://github.com/aws/amazon-braket-examples/blob/main/braket_features/Allocating_Qubits_on_QPU_Devices.ipynb

Introducing more compilation controls is very much on our radar but as awsatviraj pointed out, we don't have a timeline at this point.

Also, thanks a lot for pointing out the optimization behavior. We will investigate and get back to you.

Best, Eric

Hello @bgard

Thanks for reaching out and flagging the compilation issue you encountered, we have reported the issue to Rigetti, and they have implemented an additional check to validate fidelities, so you should no longer encounter “-1” fidelities or see them impact compilation steps.