[Trilinos-Users] Slow AztecOO solve time

[Randall Bramley]

>> I'm a student, and a beginner with Trilinos trying to use the AztecOO
>> solver in a SPICE package.   I am getting relatively slow results,

Circuit simulation problems are notoriously difficult for iterative solvers 
with non-specialized preconditioners like ILUt, etc. It's not just a matter
of a bad condition number, but the overall eigenvalue distributions tend to
give worst-case properties for Krylov solvers. That would explain having a
large number of iterations, but not necessarily the time spent in memory
management - unless it is used on every iteration, or you have an lax
dropping parameter set in the preconditioner (and hence many fill-in
locations). So this may not be of help on your problem but be aware that
just about any iterative solver package (e.g., Hypre, PETsC, ...) will in
general perform slowly for SPICE.

There may be some specialized application-specific preconditioners available
now for circuit simulation, but I've been out of the game for too long to
know. Still, that is something I'd recommend hunting for - it would well
repay a couple of hours on Google if such a magic preconditioner has been
developed. And if you do find such a thing, please post it back to this mail
list - a lot of us would be interested and grateful.

Way back when *I* was a student (shortly after the War of 1812) we typically
had to bite the bullet and use a direct sparse solver rather than iterative
methods. Or more accurately, a complete LU decomposition followed by a few
steps of iterative refinement. Ain't no such thing as purely direct or
purely iterative solvers nowadays and all practical solvers like Trilinos
are essentially hybrids.

Mike's recommendation is good, but I'd go further. You can get a quick 
estimate of the number of nonzeros (and sparsity pattern) of the LU factors
when using SuperLU or UMFPACK. Take that number, multiply by 8 to get the
number of bytes, and see if that fits inside the amount of memory you have
on the target machine. For parallel solves like SuperLUdist you'd want to
do the same on a per process basis.  Using memory size can also be used to 
determine how much fill-in would be optimal for a solver, modulo adding in
3-10 vectors for the iterative solver.