HIP loses the imaginary part on ROCM 7

[eessmann]

When building and running QuEST with ROCM 7, we lose the imaginary components of the state vector. For example, here’s a qureg initialised with a random pure state vector and we still lose the imaginary components regardless of how I initialise it.

Qureg (4 qubit statevector, 16 qcomps, 360 bytes in gpu):
    0.23598     |0⟩
    0.19536     |1⟩
    -0.25405    |2⟩
    -0.14684    |3⟩
    0.11705     |4⟩
    -0.045575   |5⟩
    -0.0095484  |6⟩
    0.42606     |7⟩
    0.082763    |8⟩
    -0.10199    |9⟩
    -0.19393    |10⟩
    0.027218    |11⟩
    -0.019831   |12⟩
    -0.21442    |13⟩
    -0.11921    |14⟩
    -0.090414   |15⟩

Total probability: 0.5017

[eessmann]

There seem to be two ways to handle complex numbers in CUDA:
from <cuda/std/complex>

cuda::std::complex<double> a

Basically a works like the c++ complex number and has all the nice overloads and documentation.
from cuComplex.h

cuComplex c

I can't find any real documentation on it, apart from that it exists.

[TysonRayJones]

Oh that's shocking! Are the unit tests failing in that configuration? I believe they should because they compare to a CPU implementation which (often) has a hardcoded non-zero imaginary component (e.g. here), but just making sure.

I lean away from cuda::std::complex<double>, given its non-standardness (I'd sooner choose thrust::complex). But that's moot because the current cuComplex is the recommended way to go (despite the unusual doc situation). HIP explicitly supports it, and it's what the NVIDIA cuQuantum software suites primarily use (see example here). So it's certainly too early to go seek another complex type hehe.

Can you share some example code doing this failing initialisation?

[TysonRayJones]

Btw beware that complex overloads sometimes have performance issues