Enhancements to VQC workflows

[ce-secqai]

Overview:

(I believe) I have to implement workarounds to optimize parameterized circuits, these workarounds could themselves be further enhanced

Request:

An enhancement that allows me to input a PyTorch or Cupy array as the parameters of a circuit.
....(This is related to, but not superseded by, NVIDIA/cuda-quantum#1480)
Improved support for tracing over indices in einsum.state_vector, etc.
Or pointing out the obvious thing I've missed.

Discussion:

Hello!

I am a cuQuantum/cuda-quantum neophyte, so if I'm missing something obvious, please point it out.

I work with diverse VQCs that I define in Qiskit and then optimize the parameters. It is important to my workflow to be able to take a circuit off the shelf and repeat the entire optimization from scratch.

I am, for the moment, very happy with the classical optimization of parameters that cuQuantum allows me to use through CircuitToEinsum, then cuquantum.contract this is excellent.

However, the rest of my of my workflow in cuQuantum is manipulating said einsum, both expression and arguments, to work around the limitation that the input circuit be fully parameterized, and this is the pain-point I'm raising here.

It would be nice if we had an easier way of inputing parameters to an cuquantum.Network, unless I've missed something.

Currently I'm working around this by manipulating the arguments of my network directly, but this workaround would be greatly enhanced if einsum.amplitude or einsum.state_vector allowed for partial inputs of parameters, others to be set during the index contraction, and/or allowed for more easily tracing over inputs rather than fixing them to specific pauli strings. I.e. I want the state_vector for qubits 0-3, where qubits 4-16 are traced out.

I note the above is a solution, not a requirement, so I would generally shy away from such a suggestion. Generically, my requirement is 'make it easier to work with VQCs'. However, I believe the intermediate solutions I suggest above are themselves a good feature to have, which is why I'm suggesting it.

I further note that qiskit_aer and the related PyTorch wrapping almost uses a similar workaround, but in the end sends the parameters to CPU to define a circuit that is then simulated on GPU, rather than creating the input matrices on GPU. So their solution hits a significant bottleneck. This may not be your problem, but I thought you might be interested.

Cheers!

[yangcal]

Hello,

We do understand that one pain-point for VQE support in CircuitToEinsum is that the input circuit is required to be fully parameterized. We may be able to lift this requirement in the future but we would like to understand your problem better.

So in the current setting, if you want to change parameters from run to run, you'll have to create new CircuitToEinsum objects for each parameters set, therefore the time for parsing those duplicate gates are unnecessary. Is this the issue you're referring to here?

It would also be nice if you could provide a minimal example to show your current workflow and then we may be able to come up with something that works for your case.

[ce-secqai]

Hi again,

Sorry for the slow reply. There are two workarounds to changing parameter values. One is to change the value of the relevant matrix directly in the arguments, the second is to pass the parameter in as the initial value of a qubit (after an rx) and then trace over that qubit in the output (which is what I'm doing).

So in this trick you might replace an rx with something like:

circuit = qiskit.QuantumCircuit(2)
circuit.cx(1,0)
einsum = cuquantum.CircuitToEinsum(circuit, backend='torch')
expression00, operands00 = einsum.amplitude('00') # "a,b,abcd,c,d->"
input_qubits_and_gates_expression = expression00[:-6]
output_qubits_expression = expression00[-6] # generically I slice this
new_expression = input_qubits_and_gates_expression + "->" + output_qubits_expression # "a,b,abcd->c"
new_operands = operands00[:-2]

Then simulate with new_expression and new_operands. To use a parameter values you just need to change the initial value of new_operands[1].

This has two drawbacks. First, automating this surgery for an arbitrary circuit is a pain because neither amplitude or state_vector give the option to trace over some qubits, but not others. Second, for large circuits, working with the einsum directly runs out of unicode characters.

Cheers!

[yangcal]

Hello,

For the particular example your provided, the easiest way is to directly do a bit post-processing on the state vectors einsum subscript. The operands from CircuitToEinsum.state_vector() can be directly reused. I'm getting a 1D torch tensor with size 2:

def get_traced_sv_expression(sv_expr, target_modes):
    inputs, output = sv_expr.split('->')
    new_expr = inputs + '->' +''.join([output[m] for m in target_modes])
    return new_expr

circuit = qiskit.QuantumCircuit(2)
circuit.cx(1,0)
einsum = cuquantum.CircuitToEinsum(circuit, backend='torch')

sv_expr, operands = einsum.state_vector() # parse only once
traced_sv_expr = get_traced_sv_expression(sv_expr, [0])
output = cuquantum.contract(traced_sv_expr, *operands)
print(traced_sv_expr, output.shape)

Let me know if this fits your workflow. I'm still having issues understanding how this is related to VQE, do you have more examples on how the parameterized gates come into the problem?

[ce-secqai]

Hi,

Thank you for the alternative workaround. Though, I believe it is fundamentally the same solution. What I was asking was for some methodology to trace over certain qubits in einsum.state_vector without having to resort to index surgery.

If this is not something that can currently be done, I am hoping this may be an enhancement made in the future!

This workflow enables differential simulation of VQCs (variational quantum circuits, not VQEs) because you can modify the relevant elements of operand to insert different values of your parameters. If you use PyTorch as the backend it is then happy to optimize over the values of the input parameters, you just have to be sure that the two circuits. rx(0)~rx(1)cx(1,0). Then you can calculate the effect of the rx on 1 in torch directly.

Ideally this would also not be required in the future, you give it an parameterized circuit without setting the parameters and it returns a function that takes a torch.tensor and then simulates.

Cheers,

Christopher

[yangcal]

Hey Christopher,

Do you have any script following the lines you've already shared? We would love to see exactly the quantities you want to compute across various operands (parameters), that would help us designing APIs that could best fit your needs.

Thanks