Modifying QAOA circuit

[bahar2040phy]

What is your issue?

Hi everyone. I need to modify the QAOA circuit by adding new gates where 'thetas' is an array of length (N=total number of qubits), containing constant rotation angles for each qubit. These gates are constant for all depth level in QAOA. The 'two_qubit_terms' and 'single_qubit_terms' are interactions between two and single qubits, respectively.

`
def circ_qaoa2(thetas, two_qubit_terms, single_qubit_terms, depth, gammas, betas, **circuit_opts,):

            circuit_opts.setdefault('gate_opts', {})

            circuit_opts['gate_opts'].setdefault('contract', False)

            gates = []

            for k in range(len(thetas)):

                gates.append((k, 'ry', thetas[k], k))

            for d in range(depth):

                for (i, j), wij in two_qubit_terms,:

                    gates.append((d, 'rzz', wij * -gammas[d], i, j))

                for (i, i), wij in one_qubit_terms,:

                    gates.append((d, 'rz', wij * 2 * gammas[d], i))    

                for k in range(len(thetas)):

                    gates.append((k, 'ry', -thetas[k] , k))

                for i in range(len(thetas)):   

                    gates.append((d, 'rz', -2*betas[d] , i))

                for k in range(len(thetas)):

                    gates.append((k, 'ry', thetas[k] , k))

            circ = qtn.Circuit(len(thetas), **circuit_opts)

            circ.apply_gates(gates)

            return circ`

Would you please let me know if to is the correct and efficient way to generate the QAOA circuit in quimb? When the number of qubits is less than 30, the code works well. However, for a greater number of qubits, it leads to the following error: "ValueError: Internal error while evaluating ContractExpression. Note that few checks are performed - the number and rank of the array arguments must match the original expression. The internal error was: '('too many subscripts in einsum',)'"

[jcmgray]

Hi @bahar2040phy, yes that looks like a fine way to construct the circuit.

Regarding the error, its basically comes from opt_einsum and numpy.einsum and is saying the intermediate tensors are very big! You could try a few things:

1. update quimb and cotengra, which now replaces opt_einsum for quimbs contractions and is more advanced for finding paths and specifically includes a np.einsum alternative able to handle larger inputs.
2. check the contraction cost and sizes before you perform the simulation, this is an essential step for TN simulations. Some details can be found here: https://quimb.readthedocs.io/en/latest/tensor-circuit.html#rehearsals. In general these simulations are exponentially expensive so there is only so much better contraction paths and backends can yield.

[bahar2040phy]

Thanks @jcmgray for the clarifications and your suggestions. I have tried different path optimizers and backends. In my case, after rehearsing the computation, the maximum contraction width is around 36. This indicates that the required memory will be 17GB, as determined during the rehearsal. However, when I run the code, it needs 120GB, otherwise it gives an "out of memory" error. Are there any other factors that could be contributing to the increased memory usage? Thanks

[jcmgray]

I think unfortunately a single complex64 tensor of that size is more like $8 \times 2^{36}=$ 550GB, and you'd probably need 2 or 3 times that, since contractions involve several tensors.

However that is probably in the range that sliced contraction can handle - you will just need to investigate a higher quality optimizer and use 'slicing'. cotengra has a preset here you could try: https://cotengra.readthedocs.io/en/latest/basics.html#high-quality-sliced-optimizer, and more details here: https://cotengra.readthedocs.io/en/latest/advanced.html#slicing-and-subtree-reconfiguration.