TysonRayJones
commented
2 years ago Hi there,
I started rambling below about the difficulties in a different but related feature, before I realised that the partial trace is relatively straight-forward algorithmically. Feel free to ignore the section at the bottom, which I'm leaving up just so I have the text somewhere, should I need to explain it later. Apologies for that confusion!
I agree the partial trace is very useful, which makes me suspicious of whether I encountered a problem trying to implement it earlier. When we add a new function to QuEST, we must write separate multithreaded, distributed and GPU-accelerated implementations, to maintain our platform agnosticism (read torture below). I can intuit that the distributed implementation of the partial trace threatens to be a nuisance, since it will take a distributed type (big density matrix) and produce a new distributed type (reduced matrix), which will be distributed differently (a different number of matrix elements on each node). We have some functions like this, made possible because some symmetry or constraint allowed the communication to be simplified. For example in calcFidelity(), we realised that a node will contain as many elements of a state-vector, as it contains columns of an equal-#qubits density matrix. If such observations aren't possible, suddenly distributed functions handling different-sized types require a multitude of edge-cases, and poorly-scaling communication patterns.
I'll add investigating distributed partial traces to my TODO list, but I can't promise it will end up being feasible! In any case, thanks very much for excellent suggestion!
Unrelated ramble
We have internally discussed [different function, grr] a lot, but hit a major design snag. Such operations typically require linear algebra routines, for example matrix diagonalisation, and hence necessitate using an external library. This poses two major problems for us:
- We want QuEST to remain light-weight and dependency free, and as trivial to get running as it is now. Unfortunately linear algebra libraries can be very hefty, and can take considerable time to install, so we are hesitant to make one a core dependency. We are considering adding an optional QuEST build with some dependencies and additional functions, but there is a lot to think through first.
- QuEST is currently agnostic to platform (multithreaded vs distributed vs GPU-accelerated), agnostic to precision (float, double vs long double through our
qrealtype) and agnostic to language (C vs C++).- There are no linear algebra libraries that share this profane level of agnosticism; finding even a distributed linear algebra library is hard enough!
- We have experimented with building against multiple libraries at once, though this brings many new problems (we may need
3*3*2 = 18libraries, and different 'glue' between QuEST for each). - We are hesitant to use just one library, constraining the user to a particular precision or platform in order to access additional functions like this, since this muddies our attribute of being "totally agnostic".
We have explored writing our own routines for things like matrix diagonalisation, but this brings even more problems (for example, it was non-trivial to conform canonical distributed diagonalisation algorithms with our present distributed memory architecture, and we would need to perform things like GPU tuning ourselves). As you can tell, computing a decomposition on one platform is (relatively) easy, but offering the facility for QuEST's full user domain is near impossible! We haven't yet given up on this, since we agree it's a very useful feature, but we need a bit more time to think about the design.
Currently there is no way to get a reduced density matrix representation of a density matrix, But a method that would calculate partial trace or Einstein summation of a matrix on target qubits could make that possible.