[Trilinos-Users] Slow AztecOO solve time

[Neal Parsons]

Thank you all for your responses. Since our SPICE package generally 
deals with smaller circuits, it sounds like Amesos/KLU solver would be 
better than the iterative AztecOO solver. I'm working for a very small 
software company for the summer that currently uses the Berkely SPICE 
engine, which fails roughly 1/3 of our NCSU benchmark test suite. The 
motivation for integrating Trilinos libraries comes from reading about 
XYCE's use of Trilinos.  We are hoping to get better convergence and 
faster results.

Our solvers were updated to solve J*deltaX(k+1) = -f, as Xyce does. We 
initially used AztecOO Line Search Based solver with ILU 
preconditioning for our solver. This gave accurate operating point 
results, but as noted, was generally slow for transient computations. 
After wrestling with AztecOO for several weeks to no avail and given 
the advice here, it appears that my next step would be to change-over 
from AztecOO to Amesos/KLU. I just want to make sure that this 
implementation will be beneficial to our application. Also, any other 
suggestions might be helpful as well. Again, thanks for your help.

Neal Parsons


Quoting "Hoekstra, Robert J" <rjhoeks at sandia.gov>:

> As Mike mentioned, KLU (by Tim Davis, also the originator of the
> aforementioned UMFPack)
> which is the default solver in the Trilinos/Amesos package has specific
> optimizations for
> circuit problems and should outperform the more generic tools (UMFPack
> and SuperLU) for
> sparse direct solves.  As mentioned by both Mike and Randy, it is very
> difficult to get
> iterative sparse methods to perform well on this class of problems.  For
> the Xyce simulator,
> (Sandia's in house tool) we use GMRES with ILU(k) preconditioning only
> for very large scale
> problems (approaching a million or more devices).  If you are bent on
> demonstrating an
> iterative method rather than performance our default usage is along the
> lines of:
>
> AztecOO GMRES
> EpetraExt Singleton Filtering
> Ifpack ILU(k) w/ RCM Reordering
>
> Just using AztecOO's ILU(t) may do the trick but I am not sure if you
> will get the RCM
> reordering by default and it's bandwidth minimization is critical to the
> performance of
> the preconditioner.  You can probably neglect the singleton filter
> unless you have a very
> large distributed problem but not the bandwidth minimizing reorder
> (approx. minimum degree
> works even better than RCM and is what Tim Davis uses in KLU but it is
> not available in Ifpack
> or AztecOO).
>
> Robert Hoekstra
> ____________________________
> Electrical & Microsystems Modeling
> Sandia National Laboratories
> P.O. Box 5800 / MS 0316
> Albuquerque, NM 87185
> phone: 505-844-7627
> fax:      505-284-5451
> e-mail: rjhoeks at sandia.gov
> web: http://www.cs.sandia.gov
>
>
>
>
> -----Original Message-----
> From: trilinos-users-bounces at software.sandia.gov
> [mailto:trilinos-users-bounces at software.sandia.gov] On Behalf Of Randall
> Bramley
> Sent: Thursday, July 12, 2007 12:37 PM
> To: Heroux, Michael A
> Cc: trilinos-users at software.sandia.gov
> Subject: Re: [Trilinos-Users] Slow AztecOO solve time
>
>
>>> 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.
>
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users
>
>
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users
>
>
>
>