Hello Stefano
I believe this was an issue that was discussed in another thread opened by me (this one I think: https://lists.mcs.anl.gov/pipermail/petsc-users/2021-April/043629.html). In any case thanks for fixing it, and glad to be of service! - Peder ________________________________ Fra: Stefano Zampini <[email protected]> Sendt: 2. juni 2021 21:43:43 Til: Peder Jørgensgaard Olesen Cc: Jose E. Roman; [email protected] Emne: Re: [petsc-users] SLEPc: non-real singular vectors from SVD of real matrix Peder We have a fix for the hdf5 complex reader here if you want to give it a try https://gitlab.com/petsc/petsc/-/merge_requests/4044 [https://assets.gitlab-static.net/uploads/-/system/project/avatar/13882401/PETSc_RBG-logo.png]<https://gitlab.com/petsc/petsc/-/merge_requests/4044> fix MatLoad_Dense_HDF5 (!4044) · Merge requests · PETSc / petsc · GitLab<https://gitlab.com/petsc/petsc/-/merge_requests/4044> gitlab.com follow-up !3903 add src/mat/tests/ex84.c... Sorry it took so long and thank you for reporting the bug On Apr 29, 2021, at 2:55 PM, Peder Jørgensgaard Olesen via petsc-users <[email protected]<mailto:[email protected]>> wrote: Thank you for your advice, Jose. I tried using a single column of the data matrix as a basis for left singular vector space, and a row for the right one - and lo and behold, all singular vectors become real. Somehow it did not occur to me that I was I was looking at was simply a complex phase on U and V which would cancel upon computing UΣV*. In other words, rather than an incorrect result it was a slightly inconvenient representation of a correct result. Best regards Peder ________________________________ Fra: Jose E. Roman <[email protected]<mailto:[email protected]>> Sendt: 29. april 2021 13:00:03 Til: Peder Jørgensgaard Olesen Cc: [email protected]<mailto:[email protected]> Emne: Re: [petsc-users] SLEPc: non-real singular vectors from SVD of real matrix In complex scalars there is no way of knowing if the user-provided matrix is real or not. If there was an option of MatSetOption() we could use it. If you set a real initial vector with SVDSetInitialSpaces(), then most probably the computed singular vectors will be real. But still rounding errors could introduce a nonzero imaginary part. In any case, you could normalize the computed singular vectors, as is done for instance in FixSign() in this examplehttps://slepc.upv.es/documentation/current/src/nep/tutorials/ex20.c.html Jose > El 29 abr 2021, a las 12:42, Peder Jørgensgaard Olesen via petsc-users > <[email protected]<mailto:[email protected]>> escribió: > > Hello > > I've noticed that doing a singular value decomposition of a real matrix > appears to result in non-real singular vectors. This should not be the case - > singular vectors of a real matrix must be real-valued. > > In the example attached I read a matrix from a binary file (also attached), > perform the SVD, and write singular vectors to an HDF5 file which I > subsequently inspect using h5dump, revealing non-zero imaginary parts of > vector elements as highlighted below: > [pjool@svol mwes]$ h5dump -d U0_sample_svd -c "5,2" sample_svecs.h5 > HDF5 "sample_svecs.h5" { > DATASET "U0_sample_svd" { > DATATYPE H5T_IEEE_F64LE > DATASPACE SIMPLE { ( 882, 2 ) / ( 882, 2 ) } > SUBSET { > START ( 0, 0 ); > STRIDE ( 1, 1 ); > COUNT ( 5, 2 ); > BLOCK ( 1, 1 ); > DATA { > (0,0): 0.0226108, 0.0299595, > (1,0): 0.035414, 0.0469237, > (2,0): 0.0276317, 0.0366122, > (3,0): 0.0145344, 0.0192581, > (4,0): 0.0110376, 0.0146249 > } > } > ATTRIBUTE "complex" { > DATATYPE H5T_STD_I32LE > DATASPACE SCALAR > DATA { > (0): 1 > } > } > } > } > I also extract the imaginary part of the input matrix and print its norm to > ensure that the matrix is indeed real. > > I'm running v3.14, but I don't believe that alone should cause the issue, > since it what I'm trying to do appears like a rather common and basic task. > > What might be the reason behind this behavior, and what can be done to > resolve it? > > > Med venlig hilsen / Best Regards > > Peder Jørgensgaard Olesen > PhD Student, Turbulence Research Lab > Dept. of Mechanical Engineering > Technical University of Denmark > Niels Koppels Allé > Bygning 403, Rum 105 > DK-2800 Kgs. Lyngby > <read_bin.c><sample_data>
