Computing expval and var with LightningTensor using quimb MPS

[PietropaoloFrisoni]

Context: This PR implements the support for expectation values and variances with the new LightningTensor device, introduced in #671. The implementation focuses on quimb as a backend and MPS as a method and includes unit tests.

Now that #671 has been merged into master, the structure of PRs for implementing the new device is the following:
This PR -> master branch

Description of the Change: This specific interface, following the new device API structure, now supports qml.expval and qml.var. Extensive unit tests are added to show how the new implementation can be used.

Benefits: This PR will enable the execution of circuits for the new LightningTensor class, allowing the computation of expectation values and variances for simulations of quantum circuits based on Tensor Networks techniques.

Possible Drawbacks: This implementation does not require changing the existing code, so drawbacks should not exist now. Since this device is still in the prototype phase, every drawback emerging during such a period will be addressed.

Note 1: At this stage, for 3 and 4-qubit gates, we need to perform a recursive decomposition until the gates are decomposed into 1 and 2-qubit gates (the reason is that the CircuitMPS class in quimb does not support the former for row-array data). Therefore, this interface is expected to be slow for circuits containing many 3 and 4-qubit gates.

Edit: Such decomposition has been removed with quimb 1.8.1. Although it has not been released, we are installing the dev version from github.

Note 2: Compared to lightning.qubit or default.qubit, we have additional overhead, and the device is much slower for circuits with a few qubits. The speed-up should become relevant for many qubits (above 10-15, depending on several factors). Performing benchmarks of this new device is currently a WIP.

Related GitHub Issues: None.

[sc-60381]
[sc-60382]

[mudit2812]

Looks great! Nice work @PietropaoloFrisoni . I'm ready to approve, but before I do I want to confirm whether or not we want to start adding the LightningTensor class and QuimbMPS class to the docs.

[mudit2812]

Discussed offline, docs are not part of the prototype device epic, so approving :)

[Qottmann]

Looks very cool, great work so far @PietropaoloFrisoni !

Mainly just some observations from my side.

Should we give a default to contract?

Getting this odd error:

from pennylane_lightning.lightning_tensor import LightningTensor

@qml.qnode(LightningTensor(contract=True, max_bond_dim=100))
def circuit():
    qml.Hadamard(0)
    qml.CNOT((0, 1))
    return qml.expval(Z(0))

circuit()

...
[~/anaconda3/envs/pennylane311/lib/python3.11/site-packages/quimb/tensor/tensor_core.py](https://file+.vscode-resource.vscode-cdn.net/Users/korbinian.kottmann/Xanadu/Sandbox2/~/anaconda3/envs/pennylane311/lib/python3.11/site-packages/quimb/tensor/tensor_core.py) in ?(.0)
-> 4860     def _get_tids_from(self, xmap, xs, which):
   4861         inverse = which[0] == "!"
   4862         if inverse:
   4863             which = which[1:]

KeyError: '_71002bAAAAg'

On another matter, I was wondering if something like this could be (made) possible.

dev = LightningTensor(contract=True)

tape = qml.tape.QuantumScript([qml.Hadamard(0)], [qml.expval(qml.Z(0))])
dev.execute([tape], max_bond_dim=100)

I think it would be very handy if I could switch the max_bond_dim upon execution to be able easily do finite size scaling without having to create separate devices for every bond dimension. I thought this was possible with the new device API, perhaps I am doing something wrong here?

[PietropaoloFrisoni]

@Qottmann Thanks for bringing up this. That error is due to the fact that the wires argument is optional forLightningTensor (this was a requirement for the first epic). Right now you must run the example as:

from pennylane_lightning.lightning_tensor import LightningTensor



@qml.qnode(LightningTensor(max_bond_dim=10,  wires=qml.wires.Wires(range(2))))
def circuit():
    qml.Hadamard(0)
    qml.CNOT((0, 1))
    return qml.expval(qml.Z(0))

circuit()

This is not ideal, but the full integration with qml.node will be part of the second epic (after the setup.py file will be updated to include the lightning.tensor entry point), so it won't be an issue in the future.
Same for the second point: being able to specify runtime configuration is part of the requirements for the second epic 👍

[multiphaseCFD]

Nice work @PietropaoloFrisoni ! Just a few minor comments.

[multiphaseCFD]

Happy to approve! Don't forget to add //TODO for tests we discussed.

[vincentmr]

[sc-61946]