-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computing expval
and var
with LightningTensor
using quimb
MPS
#686
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline, docs are not part of the prototype device epic, so approving :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@Qottmann Thanks for bringing up this. That error is due to the fact that the
This is not ideal, but the full integration with |
…ugh the lines are tested)
…es are tested indeed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @PietropaoloFrisoni ! Just a few minor comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to approve! Don't forget to add //TODO
for tests we discussed.
[sc-61946] |
…ce in PL lightning (#5699) **Context:** This PR moves part of the `lightning.tensor` device from PennyLane lightning to PennyLane. Such a device was introduced originally in the following pull requests: [1](PennyLaneAI/pennylane-lightning#671) and [2](PennyLaneAI/pennylane-lightning#686). Due to requirements change, it has been decided to create an additional `default.tensor` device and move it to the PennyLane repository. Specifically, we move the `quimb` interface and the corresponding Python implementation of `lightning.tensor` into `default.tensor`. For reference, the PR removing such a component from `lightning.tensor` is [here](PennyLaneAI/pennylane-lightning#737). *Please note that the full documentation for such a device will be added in a following PR* **Description of the Change:** As above. **Benefits:** Having two separate devices simplifies the distinction between the C++ and the Python components. The relationship between `lightning.tensor` and `default.tensor` will be similar to that between `lightning.qubit` and `default.qubit`. **Possible Drawbacks:** None with the existing code, since this is a new quantum device. **Related GitHub Issues:** None. **Related Shortcut Stories:** [sc-63256] [sc-62979] --------- Co-authored-by: albi3ro <[email protected]>
Context: This PR implements the support for expectation values and variances with the new
LightningTensor
device, introduced in #671. The implementation focuses onquimb
as a backend andMPS
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
andqml.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 inquimb
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
ordefault.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]