This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@1tnguyen Made the PR sir.

Try it out please. It's going to run fine, but will have a logical error which causes the fidelity to be near 0. This has to do with cudaq, because if you just switch to qiskit for those few lines, it works correctly (0.90 fidelity).

Have you had a chance to view the PR?

It's going to run fine, but will have a logical error which causes the fidelity to be near 0. This has to do with cudaq, because if you just switch to qiskit for those few lines, it works correctly (0.90 fidelity).

One thing to verify is the MSB-LSB convention in the unitary matrix data. You might want to debug it with just a single 2-q unitary gate to verify.

Copy. Will check that now.

I tried different ways for MSB-LSB. I don't think it's that.

Here's how I tried the note you mentioned:

from qiskit import QuantumCircuit
from qiskit.quantum_info import Statevector, Operator

qc = QuantumCircuit(2)

qc.u(0.1, 0.2, 0.3, 0)
qc.cx(0, 1)

op = Operator(qc).data

neq = cudaq.make_kernel()
qr = neq.qalloc(2)
cudaq.register_operation("unitary_0", op)
neq.unitary_0(qr[0], qr[1])

print(np.array(cudaq.get_state(neq)))
print(Statevector(qc).data)

They're identical, which to me means that it should be practically a drop-in replacement for qiskit version that I have. I'll have a closer look, maybe I have accidentally broken something.

I re-checked my qiskit one, it's correct:

# qiskit fidelity
(1+1.1102230246251565e-16j)
# cudaq fidelity
(0.07910469610639978-8.286664368584162e-09j)

from qiskit import QuantumCircuit
from qiskit.quantum_info import Statevector, Operator

qc = QuantumCircuit(2)

qc.u(0.1, 0.2, 0.3, 0)
qc.cx(0, 1)

op = Operator(qc).data

neq = cudaq.make_kernel()
qr = neq.qalloc(2)
cudaq.register_operation("unitary_0", op)
neq.unitary_0(qr[0], qr[1])

print(np.array(cudaq.get_state(neq)))
print(Statevector(qc).data)

I think the above example exhibits symmetry, hence it cannot expose the differences just by looking at the output state vector starting with the |00> initial state.

A different test with a true random unitary will show the differences:

from qiskit import QuantumCircuit
from qiskit.quantum_info import Statevector, random_unitary
from qiskit.circuit.library import UnitaryGate

import cudaq
import numpy as np 

unitary_mat = random_unitary(4)

circuit = QuantumCircuit(2)
circuit.append(UnitaryGate(unitary_mat), [0, 1])
print("Qiskit state:")
print(Statevector(circuit).data)


neq = cudaq.make_kernel()
qr = neq.qalloc(2)
cudaq.register_operation("unitary_0", unitary_mat.data)
neq.unitary_0(qr[0], qr[1])
print("CUDA-Q state:")
print(np.array(cudaq.get_state(neq)))

The second and third elements are swapped, consistent with the difference in the bit-ordering convention.

@1tnguyen Fixed it. Thank you. Should now yield 1.0.

@1tnguyen Should be finished now.

/ok to test 8caf17a

Command Bot: Processing...

@1tnguyen Should be finished now.

Could you please follow the instructions here to add a DCO remediation commit?

We require that all commits are signed off (with -s option when doing git commit)

Also, you'll need to install prerequisites (e.g., quimb) to fix this CI failure. This application notebook is an example of prerequisite installation (see the first cell)

Thanks!

@ACE07-Sev This is looking good 👍

I have a question: how does the num_layers parameter interact with target_fidelity parameter?

From what I can see, the decomposition might finish even though it didn't reach the target_fidelity because the number of layers limited it.

If that's the design intent, my suggestions are:

• Rename num_layers to max_num_layers as this is an upper limit for the depth.

• Add a print log when we have reached the max_num_layers but haven't reached the target fidelity (e.g., so that users can increase it if necessary)

• Also, a print log when we have achieved the target fidelity with fewer layers would be nice.

From what I can see, the decomposition might finish even though it didn't reach the target_fidelity because the number of layers limited it.

Yes. There are two cases which end the decomposition. Either we reach the number of layers K, or we reach the target fidelity before that. target_fidelity doesn't force more layers until it reaches the target fidelity for two reasons:

• Ran layers converge very slowly, i.e., you may reach 0.995 with 4-5 layers but then need 20+ to reach 0.999. It's simply not worth it. That you need to optimize variationally as it's cheaper and operates within the depth of Ran's layers.
• Assuming it can't reach that target fidelity, it may run for hours, maybe days because the more layers it generates, the slower the convergence gets, so it may plateau before it can get there. One case which I found for this to be the issue deterministically has been the random clifford circuits. I haven't had a chance to fully analyze it, but I noticed fidelity is much lower with these states compared to utterly randomly generated states.

I wouldn't recommend forcing more layers. Of course, I'll add them now.

/ok to test 1ff26f1

Command Bot: Processing...

@1tnguyen Should be finished now.

Could you please follow the instructions here to add a DCO remediation commit?

We require that all commits are signed off (with -s option when doing git commit)

Also, you'll need to install prerequisites (e.g., quimb) to fix this CI failure. This application notebook is an example of prerequisite installation (see the first cell)

Thanks!

Hi @ACE07-Sev,
Could you please review the CI issues related to DCO and notebook validation as mentioned above?

Copy that.

/ok to test 3b0bfd9

Command Bot: Processing...

Did I break this one?

ERROR: failed to solve: process "/bin/bash -c apt-get update && apt-get install -y --no-install-recommends         libstdc++-12-dev python3 python3-pip     && apt-get autoremove -y && apt-get clean && rm -rf /var/lib/apt/lists/*     && python3 -m pip install --no-cache-dir numpy scipy     && ln -s /bin/python3 /bin/python" did not complete successfully: exit code: 100

So,

/workspaces/cuda-quantum/docs/sphinx/applications/python/mps_encoding.ipynb: WARNING: document isn't included in any toctree

I'll add ASAP.

I noticed the index issue you mentioned in one of the failed CI, I'll investigate further. It's odd that I don't see the error on my side, may I ask if you're using a specific OS or something particular like that?

@1tnguyen Sorry to bother. When you run the latest notebook locally, do you still have the issue?

@1tnguyen Sorry to bother. When you run the latest notebook locally, do you still have the issue?

Yea, I can run the notebook locally without an issue.

For the CI failures:

(1) The documentation build: we can build the docs locally using this script if needed. This will probably reproduce the error that we've seen in the CI.

It looks like we're missing an entry in this applications.rst file

(2) For the notebook validation failure, we might need to add a special notebook cell with commands to install extra prerequisites.

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

Any of the failed CIs that failed due to my side?

Fixing the spelling check.

/ok to test 74f426f

Command Bot: Processing...

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

/ok to test 54ac131

Command Bot: Processing...

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

Sorry to bother. Could I ask when this will be merged? I would like to work on other issues but I am not allowed to make new PRs if I have 4 PRs open.

I apologize for the inconvenience.

/ok to test fa50675

Command Bot: Processing...

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

/ok to test 17698b8

Command Bot: Processing...

CUDA Quantum Docs Bot: A preview of the documentation can be found here.