Why does gmres command run for quite a long time?

Hi,

I solved a system with gmres and preconditioners. It worked for several meshes and converged after 2 iteration steps for all A of dimensions up to and only needed a few seconds to solve the system. Refining the mesh again yields A of size . When I now try to solve the system, gmres needs 22 minutes and 2 iteration steps (instead of a few seconds). Does anyone have any ideas why gmres takes much longer for the finer mesh?

Thanks in advance!

[John D'Errico]

Is A sparse? How sparse? Is A stored as a sparse matrix?

[Harald]

Hi,

have a look at the RAM usage on your machine.

If A is a double full matrix (i.e., not stored as sparse), it will require about 12.8 GB of memory (40000^2 * 8 bytes, to be precise). This may be pushing the limits of your machine to the extent that the system starts to swap, meaning hard disk space is used to extend RAM. This avoids out of memory errors but slows things down significantly.

Best wishes,

Harald

[dpb]

t=fsolve(@(t)(40/10)^2*t/60-22,30)

Equation solved.

fsolve completed because the vector of function values is near zero
as measured by the value of the function tolerance, and
the problem appears regular as measured by the gradient.

t = 82.5000

If the solution time were about 1 minute, it would be almost linearly scaled with problem size even without any disk swapping. Certainly doesn't seem unreasonable.

@Philip Johann, besides @John D'Errico query about sparseness, see how it changes if you take several intermediate mesh sizes and whether it at some point takes a quantum leap or is otherwise some power law relationship.

[Philip Johann]

Thanks for your responses. My matrix is sparse and I found the issue. I have used L,U in A = L*U as preconditioners and had a very low 'droptol' value, which increased the running time of the gmres command.

[Torsten]

But if you have an LU decomposition, why do you use gmres at all ? Or do you mean ILU ?

[John D'Errico]

@Torsten I assume when @Philip Johann said lu was used, it could only have been an incomplete LU, used to build a preconditioner, because of the droptol comment.

A very low drop tolerance makes the incomplete LU nearly a complete LU. There is a tradeoff in this. As you make the ILU nearly complete (a droptol of zero should be effectively a complete LU) you will see a geat deal of fill-in, therefore using a great deal of memory. That may be just pushing the limits of your memory. A better preconditioner should make convergence better/faster, but if you are incurring serious memory problems, it matters little. Just trying to use/build that incomplete LU is probably the issue.