v3.7.0 #387
Merged
v3.7.0 #387
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note that this forces our cuQuantum backend to require its users to have a stream-ordered memory pool compatible GPU (which seems fair enough)
for converting between QuEST's interface and backend types (like Complex, ComplexMatrixN, and bitmasks) and cuQuantum's
Added all operators (like unitaries, sub-diagonal gates) which can be directly mapped to a cuQuantum calls. The cuQuantum calls are: - custatevecApplyMatrix - custatevecApplyPauliRotation - custatevecSwapIndexBits - custatevecApplyGeneralizedPermutationMatrix It appears that the remainder of QuEST's operators (decoherence channels, full-state diagonals, and phase functions) will need bespoke kernels
Before each unit test, the initial state of the registers (assumed to be in the result of initDebugState) is now explicitly checked. This prevents passing tests when initDebugState() itself is failing, and (for example) yielding an all-zero state which sneakily satisfies some unit tests. This will likely noticeably increase the total unit-tests runtime, but will gaurantee tests visibly, instantly fail when (for example) the GPU configuration is wrong and produces all-zero states
since documentation is now generated by Github Actions and published on Github Pages without repo caching
which were unavailable in the API, and were not used internally nor in tests. Furthermore, some of them (`initStateOfSingleQubit`) did something *very* different to what its comments suggested - and inefficiently!
although we are missing imports to avoid git conflict: # include <thrust/sequence.h> # include <thrust/iterator/zip_iterator.h> # include <thrust/for_each.h>
Added all decoherence channels which can be directly mapped (without unacceptable performance damage) to a cuQuantum call. The cuQuantum calls are: - custatevecApplyMatrix - custatevecApplyGeneralizedPermutationMatrix and are called with matrices (some, diagonal) describing the channel superoperators. The remaining decoherence channels require linearly combining device vectors (may use Thrust), bespoke GPU kernels, or a clever decomposition of the channel (e.g. 2 qubit depolarising) into a sequence of cuStateVec calls
Changed several operators represented by diagonal matrices but previously effected as one-qubit general matrices, to instead be effected as diagonals (duh)
integrated a new cuQuantum and Thrust GPU backend
Previously, an ad-hoc measure of distance from unitarity (or CPTP) was used. Now, a unitarity U is deemed valid only if every element of U*dagger(U) has a Euclidean distance of at most REAL_EPS from the corresponding Identity matrix element. A similiar scheme for CPTP Kraus channels is used. This effectively loosens the precision required of unitaries and Kraus maps to functions like multiQubitUnitary and multiQubitKrausMap
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This release integrates a cuQuantum backend, optimises distributed communication, and improves the unit tests.
New features
-DUSE_CUQUANTUM=1, as detailed in the compile doc. Unlike QuEST's other backends, this does require prior installation of cuQuantum, outlined here. This deployment mode should run much faster than QuEST's custom GPU backend, and will soon enable multi-GPU simulation. The entirety of QuEST's API is supported! 🎉Other changes
multiQubitUnitary()andmixMultiQubitKrausMap()have relaxed the precision of their unitarity and CPTP checks, so they will complain less about user matrices. Now, for example, a unitarity matrixUis deemed valid only if every element ofU*dagger(U)has a Euclidean distance of at mostREAL_EPSfrom its expected identity-matrix element.