For large problems, preconditioners have to take advantage of some underlying mathematical structure of the operator to perform well (require few iterations). Just black-boxing the system with simple preconditioners will not be effective.
So, one needs to look at the Liouvillian Superoperator's structure to see what one can take advantage of. I first noticed that it can be represented as a Kronecker product: A x I or a combination of Kronecker products? In theory, one can take advantage of Kronecker structure to solve such systems much more efficiently than just directly solving the huge system naively as a huge system. In addition it may be possible to use the Kronecker structure of the operator to perform matrix-vector products with the operator much more efficiently than by first explicitly forming the huge matrix representation and doing the multiplies with that. I suggest some googling with linear solver, preconditioning, Kronecker product. > On Jan 31, 2024, at 6:51 AM, Niclas Götting <ngoett...@itp.uni-bremen.de> > wrote: > > Hi all, > > I've been trying for the last couple of days to solve a linear system using > iterative methods. The system size itself scales exponentially (64^N) with > the number of components, so I receive sizes of > > * (64, 64) for one component > * (4096, 4096) for two components > * (262144, 262144) for three components > > I can solve the first two cases with direct solvers and don't run into any > problems; however, the last case is the first nontrivial and it's too large > for a direct solution, which is why I believe that I need an iterative solver. > > As I know the solution for the first two cases, I tried to reproduce them > using GMRES and failed on the second, because GMRES didn't converge and seems > to have been going in the wrong direction (the vector to which it "tries" to > converge is a totally different one than the correct solution). I went as far > as -ksp_max_it 1000000, which takes orders of magnitude longer than the LU > solution and I'd intuitively think that GMRES should not take *that* much > longer than LU. Here is the information I have about this (4096, 4096) system: > > * not symmetric (which is why I went for GMRES) > * not singular (SVD: condition number 1.427743623238e+06, 0 of 4096 singular > values are (nearly) zero) > * solving without preconditioning does not converge (DIVERGED_ITS) > * solving with iLU and natural ordering fails due to zeros on the diagonal > * solving with iLU and RCM ordering does not converge (DIVERGED_ITS) > > After some searching I also found [this](http://arxiv.org/abs/1504.06768) > paper, which mentions the use of ILUTP, which I believe in PETSc should be > used via hypre, which, however, threw a SEGV for me, and I'm not sure if it's > worth debugging at this point in time, because I might be missing something > entirely different. > > Does anybody have an idea how this system could be solved in finite time, > such that the method also scales to the three component problem? > > Thank you all very much in advance! > > Best regards > Niclas >
