Add `MPSTNCuda` class

[multiphaseCFD]

Before submitting

Please complete the following checklist when submitting a PR:

• [x] All new features must include a unit test. If you've fixed a bug or added code that should be tested, add a test to the tests directory!

• [ ] All new functions and code must be clearly commented and documented. If you do make documentation changes, make sure that the docs build and render correctly by running make docs.

• [x] Ensure that the test suite passes, by running make test.

• [x] Add a new entry to the .github/CHANGELOG.md file, summarizing the change, and including a link back to the PR.

• [x] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed line and fill in the pull request template.

---

Context:

This PR adds MPSCutn C++ class which manages cutensornet high-level C++ APIs.

Description of the Change: MPSCutn class:

• Current design allows user to set the maxBondDim for the MPS representation. More controls option on the MPS representation, like cutoff of SVD configures, will be added when introducing cutensornetStateConfigure() API, once the applyGates() or circuit_build() is done.
• setBasisState(std::vector<size_t>& basisState) initializes/sets the MPS quantum state. Please note that setBasisState() can be only called once. This is the reason why there is protected MPSInitialized_ flag in the CutnBase class. Note that current implementation on setBasisState(std::vector<size_t>& basisState) only works for qubit systems, which means the dimension of physical site is 2, like our statevector backends.
• reset() will update the MPS quantum state to zeroState. We can call either reset() or setBasisState() once, since reset() will call setBasisState() under the hood. IMPORTANT: this intrinsic feature could impact the design of the Measurement class.
• getDataVector() will return the full state vector. This is a feature only for C++ unit tests.
• cutensornetHandle, cutensornetState_t are managed by the CutnBase class. Methods, like circuit_build maybe, that can be shared by both MPS and Exact Tensor Network methods will live in the CutnBase class.

Tensor classes:

• TensorBase class wraps basic information like rank, length, modes and extents of a tensor.
• CudaTensor inherits from TensorBase class and wraps a DataBuffer object that manages the tensor data on device.

Benefits:

Possible Drawbacks:

Related GitHub Issues:

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 99.64158% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 97.97%. Comparing base (29fa26c) to head (a653027).

Files	Patch %	Lines
.../simulators/lightning_tensor/tncuda/TNCudaBase.hpp	97.67%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #704      +/-   ##
==========================================
+ Coverage   95.68%   97.97%   +2.28%     
==========================================
  Files          72      134      +62     
  Lines        8815    19348   +10533     
==========================================
+ Hits         8435    18956   +10521     
- Misses        380      392      +12     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[multiphaseCFD]

Thanks for the hard work @multiphaseCFD . I'm leaving comments, questions and suggestions in places, but there is one design issue I would like to address. It seems the current PR implements tensor classes and simulators classes which will also act as tensor network classes. I think we should have tensor, tensor network and simulator classes, where tensor networks keep track of tensors and simulators keep track of circuit execution. This may not be a 100% clear from the ADR, but it is implied. This is also how the old prototypes, the Python device and Quimb circuit classes work. Ok, maybe I read that wrong and this is where we are going, but I just want to make sure.

As discussed, we will stick to the current implementation since cuTensorNet lib unify the implementation of exact tensor network and matrix product state simulation.

[multiphaseCFD]

Will update the cutn to CudaTN and move this PR to v0.37 in the changelog once all reviewers give green lights for other comments @mlxd @vincentmr @maliasadi

[vincentmr]

[sc-61945]

[multiphaseCFD]

Thanks @AmintorDusko ! Good question! I plan to add those branch with the progress of the project since it's still not clear how can we deal with the measurement module to make it compatible for both sv and tensor backend at least cutensornet backend. Per cutensornet backend, we can build both mps and exatn at the same time.

Hey @multiphaseCFD! Nice work! Quick non-blocking general question. I see that along the building procedure you branched out the Lightning non-tensor libraries. Any special reason for that? Will LightningTensor still build if we add the Lightning libraries? I'm wondering if we would be able to build both backends at the same time (LightningQubit and LightningTensor). Also, do you see as possible to install LightningTensor with more than one backend at the same time?

[AmintorDusko]

Thanks @AmintorDusko ! Good question! I plan to add those branch with the progress of the project since it's still not clear how can we deal with the measurement module to make it compatible for both sv and tensor backend at least cutensornet backend. Per cutensornet backend, we can build both mps and exatn at the same time.

Hey @multiphaseCFD! Nice work! Quick non-blocking general question. I see that along the building procedure you branched out the Lightning non-tensor libraries. Any special reason for that? Will LightningTensor still build if we add the Lightning libraries? I'm wondering if we would be able to build both backends at the same time (LightningQubit and LightningTensor). Also, do you see as possible to install LightningTensor with more than one backend at the same time?

Thank you very much!