Update lightning.tensor docs

.github/CHANGELOG.md

@@ -66,6 +66,9 @@
 
 ### Documentation
 
+*  Update ``lightning.tensor`` documentation on all the new features.
+  [(#909)](https://github.com/PennyLaneAI/pennylane-lightning/pull/909)
+
 ### Bug fixes
 
 * Bug fix for analytic `probs` in the `lightning.tensor` C++ layer.

CMakeLists.txt

@@ -12,7 +12,7 @@ set(CMAKE_OSX_DEPLOYMENT_TARGET "11" CACHE STRING "Minimum OS X deployment versi
 set(CMAKE_CXX_STANDARD 20) # At least C++20 is required
 
 project(pennylane_lightning
-    DESCRIPTION "C++ suite of state-vector simulators bindings for PennyLane. "
+    DESCRIPTION "C++ suite of state-vector and tensor network simulators bindings for PennyLane. "
     LANGUAGES CXX
 )
 

README.rst

@@ -35,7 +35,7 @@ Lightning Plugins
 
 .. header-start-inclusion-marker-do-not-remove
 
-The Lightning plugin ecosystem provides fast state-vector simulators written in C++.
+The Lightning plugin ecosystem provides fast state-vector and tensor network simulators written in C++.
 
 `PennyLane <https://docs.pennylane.ai>`_ is a cross-platform Python library for quantum machine
 learning, automatic differentiation, and optimization of hybrid quantum-classical computations.
@@ -49,8 +49,7 @@ PennyLane-Lightning high performance simulators include the following backends:
 * ``lightning.qubit``: is a fast state-vector simulator written in C++.
 * ``lightning.gpu``: is a state-vector simulator based on the `NVIDIA cuQuantum SDK <https://developer.nvidia.com/cuquantum-sdk>`_. It notably implements a distributed state-vector simulator based on MPI.
 * ``lightning.kokkos``: is a state-vector simulator written with `Kokkos <https://kokkos.github.io/kokkos-core-wiki/index.html>`_. It can exploit the inherent parallelism of modern processing units supporting the `OpenMP <https://www.openmp.org/>`_, `CUDA <https://developer.nvidia.com/cuda-toolkit>`_ or `HIP <https://docs.amd.com/projects/HIP/en/docs-5.3.0/index.html>`_ programming models.
-* ``lightning.tensor``: is a tensor network simulator based on the `NVIDIA cuQuantum SDK <https://developer.nvidia.com/cuquantum-sdk>`_ (requires NVIDIA GPUs with SM 7.0 or greater). This device is designed to simulate large-scale quantum circuits using tensor networks. For small circuits, state-vector simulator plugins may be more suitable. The supported method is Matrix Product State (MPS). This device does not currently support finite shots. Currently, the supported measurement types are expectation values and the supported differentiation methods are ``parameter-shift`` and ``finite-diff``. Note that only 1,2-wire gates and gates that can be decomposed by PennyLane into 1,2-wire gates are supported.
-
+* ``lightning.tensor``: is a tensor network simulator based on the `NVIDIA cuQuantum SDK <https://developer.nvidia.com/cuquantum-sdk>`_ (requires NVIDIA GPUs with SM 7.0 or greater). The supported method is Matrix Product State (MPS).
 .. header-end-inclusion-marker-do-not-remove
 
 The following table summarizes the supported platforms and the primary installation mode:

doc/lightning_tensor/device.rst

@@ -1,7 +1,7 @@
 Lightning Tensor device
 =======================
 
-The ``lightning.tensor`` device is a tensor network simulator device. The device is built on top of the `cutensornet <https://docs.nvidia.com/cuda/cuquantum/latest/cutensornet/index.html>`__ from the NVIDIA cuQuantum SDK, enabling GPU-accelerated simulation of quantum tensor network evolution.
+The ``lightning.tensor`` device is a tensor network simulator device. The device is built on top of the `cutensornet <https://docs.nvidia.com/cuda/cuquantum/latest/cutensornet/index.html>`__ from the NVIDIA cuQuantum SDK, enabling GPU-accelerated simulation of quantum tensor network evolution. This device is designed to simulate large-scale quantum circuits using tensor networks. For small circuits, state-vector simulator plugins may be more suitable.
 
 A ``lightning.tensor`` device can be loaded simply using:
 
@@ -14,17 +14,18 @@ By default, the device represents the quantum state approximated as a Matrix Pro
 The default setup for the MPS tensor network approximation is:
     - ``max_bond_dim`` (maximum bond dimension) defaults to ``128`` .
     - ``cutoff`` (singular value truncation threshold) defaults to ``0`` .
-    - ``cutoff_mode`` (singular value truncation mode) defaults to ``abs`` , considering the absolute values of the singular values; Alternatively, users can opt to set ``cutoff_mode`` to ``rel`` to consider the relative values of the singular values. 
+    - ``cutoff_mode`` (singular value truncation mode) defaults to ``abs`` , considering the absolute values of the singular values; Alternatively, users can opt to set ``cutoff_mode`` to ``rel`` to consider the relative values of the singular values.
+Note that the ``cutensornet`` will automatically determin the reduced extent of the bond dimension based on the lowest among the multiple truncation cutoffs (``max_bond_dim``, ``cutoff-abs`` and ``cutoff-rel``). For more details on how the ``cutoff`` works, please check it out the `cuQuantum documentation<https://docs.nvidia.com/cuda/cuquantum/latest/cutensornet/api/types.html#cutensornettensorsvdconfigattributes-t>`__. All swap and decomposition operations in MPS-MPO multiplication will follow the same constraints set by SVD configurations (``cutoff``) and target extents setups. For more details, please refer to the `cuQuantum documentation<https://docs.nvidia.com/cuda/cuquantum/latest/cutensornet/api/types.html#cutensornetstatempoapplication-t>`__.
 
 The ``lightning.tensor`` device dispatches all operations to be performed on a CUDA-capable GPU of generation SM 7.0 (Volta)
-and greater.
+and greater. This device supports both analytical and finite shots measurements. Currently, the supported differentiation methods are parameter-shift and finite-diff. Note that MPS backend of lightning.tensor supports multi-wires gate via Matrix Product Operators (MPO). Disable the new arithmetic operator dunders is recommended since only 1-wire Hermitian is supported by lightning.tensor. It is recommended to use the shot measurements for the lightning.tensor device. The calculation of analytical probabilities and variances may result in excessive memory usage for large-scale quantum simulations or become impractical due to prohibitive computational costs. It's also recommended to disable new_opmath for the lightning.tensor device since lightning.tensor only supports 1-wire Hermitian observables.
 
-.. note:: 
-    Given the inherent parallelism of GPUs, simulations with intensive parallel computation, such as those with larger maximum
-    bond dimensions, stand to gain the most from the computational power offered by GPU and those simulations can benifit from the 
-    ``lightning.tensor`` device.  It's worth noting that if the bond dimension used in the simulation is small, the ``lightning.tensor`` 
-    device with ``MPS`` running a GPU may perform slower compared to a ``default.tensor`` device with ``MPS`` running on a CPU. For more details
-    on how bond dimension affects the simulation performance, please refer to the ``Approximate Tensor Network Methods`` section in the `cuQuantum SDK <https://developer.nvidia.com/cuquantum-sdk>`__.
+Some tips on the usage of the ``lightning.tensor`` device:
+    - ``lightning.tensor`` performs better for the larger bond dimensions in MPS calculations, see the ``Approximate Tensor Network Methods`` section in the `cuQuantum SDK <https://developer.nvidia.com/cuquantum-sdk>`__.
+    - The ``lightning.tensor`` device is recommended for large-scale quantum simulations. For small-scale simulations, the cost of SVD decomposition and MPS-MPO multiplication might outweigh than the benifits of MPS.
+    - It is recommended to use shot-based ``probs()`` measurements for the ``lightning.tensor`` device when the number of target/projected wires is large. The analytical calculation of ``prob()`` target at ``30+`` wires can lead to excessive memory usage. The analytical calculation of ``prob()`` that targets at small number of subset wires but projects a larger number of wires could become impractical due to high computational costs for large-scale quantum simulations. If the number of projected wires is ``n``, ``2**n`` times of ``cutensornet`` API calls should be made to get the analytical ``probs()``, which could be prohibitive if ``n`` is large. 
+    - The analytical calculation of ``var()`` measurements could be impractical for Hamiltonian observables with many terms. The computational cost of current ``var`` implementation scales with ``n**2``, where ``n`` is the number of terms in the Hamiltonian observable.
+    - It is advisable to disable ``new_opmath`` for the ``lightning.tensor`` device, as the device only supports 1-wire Hermitian observables.
 
 Users also have the flexibility to customize these parameters according to their specific needs with:
 
@@ -58,7 +59,7 @@ Check out the :doc:`/lightning_tensor/installation` guide for more information.
 Operations and observables support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The "lightning.tensor" supports 1- and 2-wire gate operations and all other operations that can be decomposed to that by PennyLane.
+The "lightning.tensor" supports all gate operations supported by PennyLane.
 
 **Supported operations:**
 
@@ -70,6 +71,7 @@ The "lightning.tensor" supports 1- and 2-wire gate operations and all other oper
     :nosignatures:
 
     ~pennylane.BasisState
+    ~pennylane.BlockEncode
     ~pennylane.CNOT
     ~pennylane.ControlledPhaseShift
     ~pennylane.ControlledQubitUnitary
@@ -82,7 +84,10 @@ The "lightning.tensor" supports 1- and 2-wire gate operations and all other oper
     ~pennylane.CZ
     ~pennylane.DiagonalQubitUnitary
     ~pennylane.DoubleExcitation
+    ~pennylane.DoubleExcitationMinus
+    ~pennylane.DoubleExcitationPlus
     ~pennylane.ECR
+    ~pennylane.GlobalPhase
     ~pennylane.Hadamard
     ~pennylane.Identity
     ~pennylane.IsingXX
@@ -98,6 +103,7 @@ The "lightning.tensor" supports 1- and 2-wire gate operations and all other oper
     ~pennylane.PSWAP
     ~pennylane.QFT
     ~pennylane.QubitCarry
+    ~pennylane.QubitStateVector
     ~pennylane.QubitSum
     ~pennylane.QubitUnitary
     ~pennylane.Rot
@@ -108,6 +114,7 @@ The "lightning.tensor" supports 1- and 2-wire gate operations and all other oper
     ~pennylane.SingleExcitation
     ~pennylane.SingleExcitationMinus
     ~pennylane.SingleExcitationPlus
+    ~pennylane.StatePrep
     ~pennylane.SISWAP
     ~pennylane.SQISW
     ~pennylane.SWAP
@@ -119,30 +126,10 @@ The "lightning.tensor" supports 1- and 2-wire gate operations and all other oper
 
     </div>
 
-**Unsupported operations:**
-
-.. raw:: html
-
-    <div class="summary-table">
-
-.. autosummary::
-    :nosignatures:
-
-    ~pennylane.StatePrep
-    ~pennylane.QubitStateVector
-    ~pennylane.DoubleExcitationMinus
-    ~pennylane.DoubleExcitationPlus
-    ~pennylane.GlobalPhase
-    ~pennylane.BlockEncode
-
-
-.. raw:: html
-
-    </div>
 
 **Supported observables:**
 
-The ``lightning.tensor`` supports all observables supported by the Lightning state-vector simulators, besides ``qml.SparseHamiltonian``, ``qml.Projector`` and limited support to ``qml.Hamiltonian``, ``qml.Prod``.
+The ``lightning.tensor`` supports all observables supported by the Lightning state-vector simulators, besides ``qml.SparseHamiltonian``, ``qml.Projector`` and limited support to ``qml.Hamiltonian``, ``qml.Prod`` since ``lightning.tensor`` only supports 1-wire Hermitian observables.
 
 Users can not create a ``Hamiltonian`` or ``Prod`` observable from ``Hamiltonian`` observables.
 

pennylane_lightning/core/_version.py

@@ -16,4 +16,4 @@
    Version number (major.minor.patch[-label])
 """
 
-__version__ = "0.39.0-dev24"
+__version__ = "0.39.0-dev27"