[Trilinos-Users] AztecOO: not enough memory for ILUT

Tiziano Passerini tiziano.passerini at polimi.it
Thu Feb 28 10:32:48 MST 2008


Hi Mike,

I tried fill-in = 12 after some tests, since in many other cases (e.  
g. same Navier-Stokes problem on smaller/different mesh) I noticed  
that increasing the fill-in improves a lot the convergence of gmres.

I have another job running, in which I set fill-in=6. I solve the  
linear system once with max_iter = 128, then if I don't have  
convergence I force rebuild of the preconditioner  
(options[AZ_pre_calc] = AZ_recalc) and rerun gmres using the first-run  
solution as initial guess. Usually in the second run I have  
convergence in about 50 iterations

If applying the same strategy and parameters to the ill-conditioned  
matrix, I get

**** Condition number estimate for subdomain preconditioner on PE 0 =  
1.6930e+10

and both the first and the second run do not converge in 128 + 128  
iterations, with a warning

"Warning: recursive residual indicates convergence though the true  
residual is too large"

I also have a question about domain decomposition preconditioner: is  
the matrix actually divided in submatrices even when running only on  
one processor?

Many thanks in advance for your help

Tiziano

Il giorno 27/feb/08, alle ore 20:42, Heroux, Michael A ha scritto:

> Tiziano,
>
> A fill-in level of 12 is unusually high and probably means there is  
> some better approach to consider.  Have smaller fill-in values  
> worked for you?  If not, what happens?
>
> Mike
>
>
> On 2/27/08 4:35 PM, "Tiziano Passerini"  
> <tiziano.passerini at polimi.it> wrote:
>
> Hi,
>
> many thanks for your quick answers,
>
> Il giorno 27/feb/08, alle ore 13:10, Schiek, Richard L ha scritto:
> Tiziano,
>
> Are you sure you’re building 64bit binaries?  Many 64 bit systems  
> will run both 32 and 64 bit binaries.  Check the compiler  
> documentation to be sure.  You should be able to use the “file  
> <binary_name>” to check this.  Here if I do “file myProg” and myProg  
> is a 64 bit program then I get:
>
> myProg: ELF 64-bit LSB executable, AMD x86-64
>
> ok that's what I get:
>
> ./test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for  
> GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/ 
> Linux 2.6.9, not stripped
>
>  actually I do have the feeling that my problem has something to do  
> with 64-bit binaries, but I thought I managed to control every stage  
> of the compilation process.
>
> I'm using gcc 4.2.3, which I compiled from scratch. I also checked  
> each one of the libraries which are dynamically linked by my  
> executable, and thay all are 64-bit shared objects.
>
> maybe I should force somehow the use of 64 bit int? I don't know if  
> this is feasible with gcc...
>
>
>
> Il giorno 27/feb/08, alle ore 15:23, Heroux, Michael A ha scritto:
>
> Tiziano,
>
>  Can you tell me what parameter values you are setting for ILUT?   
> Also, are you performing any local reordering for the  
> preconditioner, e.g., RCM ?
>
>  Mike
>
>
> I use ILUT fill-in = 12 and drop = 1e-5. I'm not performing local  
> reordering - I didn't think about that :) I think I'll also have a  
> deeper look at AztecOO documentation...
>
> Tiziano
>
>
>



-------------- next part --------------
Skipped content of type multipart/mixed


More information about the Trilinos-Users mailing list