[Trilinos-Users] AztecOO Convergence
Ammar T. Al-Sayegh
alsayegh at purdue.edu
Mon Nov 21 22:15:07 MST 2005
Mike and Randall,
Thank you very much for your help. It turned out that Mike
was right about having a flaw in my code. Unfortunately, the
bug went undetected all this time because of the poor quality
of the standard output stream (few significant figures, and
scrambled output). Using Epetra output functions recommended
by Mike, I was able to pinpoint the problem and have it fixed.
I assume that the Epetra output functions are still in
development stage and will be included in the standard package
in the future. If that's the case, then I would like to make
the following suggestions to improve their functionality:
1. Allow append to file option in order to be able to
update a variable on the same file as it changes instead
of creating multiple files.
2. Have the elements of maps/vectors/marices ordered for
easier inspection and comparison.
3. Use 0 as the base index instead of 1 to facilitate
debugging.
4. Allow c++ style stream objects to be created as another
form of these functions.
Thank you once again for your help.
-ammar
----- Original Message -----
From: "Mike Heroux" <maherou at sandia.gov>
To: "'Ammar T. Al-Sayegh'" <alsayegh at purdue.edu>; <trilinos-users at software.sandia.gov>
Sent: Monday, November 21, 2005 3:54 PM
Subject: RE: [Trilinos-Users] AztecOO Convergence
> Ammar,
>
> No they will not be 100% identical, but they should be very close for all
> but the most pathological matrices.
>
> One note: You can use the matrix output functions found in EpetraExt to
> help determine if your matrices are the same. Look at
> Trilinos/packages/epetraext/test/inout/cxx_main.cpp for an example of how to
> use these functions.
>
> Mike
>
>> -----Original Message-----
>> From: trilinos-users-bounces at software.sandia.gov
>> [mailto:trilinos-users-bounces at software.sandia.gov] On Behalf
>> Of Ammar T. Al-Sayegh
>> Sent: Monday, November 21, 2005 2:51 PM
>> To: trilinos-users at software.sandia.gov
>> Subject: Re: [Trilinos-Users] AztecOO Convergence
>>
>> Mike,
>>
>> Just to cofirm, if A and b of an Epetra_LinearProblem being
>> solved in a single processor are exactly the same as A and b
>> of an Epetra_LinearProblem being solved in two processors,
>> then the solution, x, should be 100% identical in both cases
>> when AZ_precond is set to AZ_none. Is this correct?
>>
>> I will try to trace my A and b before each run of
>> solver.iterate() in the single- and dual-processor cases and
>> check whether there is a variation in A and b between the two
>> cases to track any coding error.
>>
>>
>> -ammar
>>
>>
>> ----- Original Message -----
>> From: "Mike Heroux" <maherou at sandia.gov>
>> To: "'Ammar T. Al-Sayegh'" <alsayegh at purdue.edu>;
>> <trilinos-users at software.sandia.gov>
>> Sent: Monday, November 21, 2005 3:21 PM
>> Subject: RE: [Trilinos-Users] AztecOO Convergence
>>
>>
>> > Ammar,
>> >
>> > Note that, if your matrix is singular, then there are two basic
>> > possibilities:
>> >
>> > 1) Your right-hand-side b is in the range of the operator
>> A. In other
>> > words, there is an x such that A*x = b. Furthermore, there
>> are many vectors
>> > that are solutions, since any vector y from the null space
>> of A can be added
>> > to x and A(x+y) = b. If you are getting two solutions to
>> your problem in
>> > this case, say x1 and x2, and both have a small residual
>> (norm(b-A*x1) and
>> > norm(b-A*x2) are both small) then you might check the norm
>> of A*(x1-x2). If
>> > this value is small, then x1 and x2 are two particular
>> solutions to the
>> > singular problem and x1-x2 is a vector in the null space of A.
>> >
>> > 2) Your right-hand-side b is not in the range of A. Then
>> there is NO x such
>> > that A*x = b. This second case can happen in a partial way
>> due to floating
>> > point arithmetic errors. In these cases, b may be
>> analytically in the range
>> > but numerically slightly out of the range. This might
>> explain why you
>> > cannot get your error below a certain tolerance.
>> >
>> >
>> > If you are using unpreconditioned GMRES, there is little
>> chance that you are
>> > getting two wildly different particular solutions, so if
>> you are seeing very
>> > different results on 1 and 2 processors, it suggests a
>> coding error (at
>> > least to me).
>> >
>> >
>> > Mike
>> >
>> >> -----Original Message-----
>> >> From: trilinos-users-bounces at software.sandia.gov
>> >> [mailto:trilinos-users-bounces at software.sandia.gov] On Behalf
>> >> Of Ammar T. Al-Sayegh
>> >> Sent: Monday, November 21, 2005 1:59 PM
>> >> To: trilinos-users at software.sandia.gov
>> >> Subject: Re: [Trilinos-Users] AztecOO Convergence
>> >>
>> >> Randal,
>> >>
>> >> Thank you for the elaborate explanation. Your reasoning makes
>> >> sense, and I tried to follow your advice and disable the
>> >> preconditioner. However, I got hit by another issue. Now it
>> >> says that my GMRES Hessenberg matrix is ill-conditioned,
>> >> which perhaps is right because I'm dealing with nonlinear
>> >> analysis of a structure that's reaching instability, i.e.
>> >> having it's stiffness matrix getting close to being singular.
>> >> The thing that I can't make sense of, though, is that why it
>> >> works fine just fine with a single processor but not with two
>> >> processors even when preconditioner is disabled?
>> >>
>> >> I don't mind the additional time cost if there is a way to
>> >> get the same level of numerical accuracy of when using
>> >> multiple processors as in the case with a single processor.
>> >>
>> >>
>> >> -ammar
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Randall Bramley" <bramley at cs.indiana.edu>
>> >> To: "Ammar T. Al-Sayegh" <alsayegh at purdue.edu>
>> >> Cc: <trilinos-users at software.sandia.gov>
>> >> Sent: Monday, November 21, 2005 11:01 AM
>> >> Subject: Re: [Trilinos-Users] AztecOO Convergence
>> >>
>> >>
>> >> >
>> >> >> In AztecOO, why does convergence deteriorate as the number
>> >> >> of processors is increased?
>> >> >
>> >> > At last, a question I can answer. :-)
>> >> >
>> >> > The preprocessing is usually block diagonal, and as the number of
>> >> > processors increases, the blocks become smaller - in the
>> limit, the
>> >> > preconditioner becomes diagonal scaling. Fewer
>> processors leads to
>> >> > the block becoming larger, in the limit becoming an incomplete
>> >> > factorization on the whole matrix. This is generally a more
>> >> > accurate preconditioner since it brings in more
>> >> off-diagonal elements
>> >> > and hence accounts for longer-range interactions in the
>> >> linear system.
>> >> >
>> >> > So it's normal to have the quality of preconditioning lower
>> >> (and hence
>> >> > number of iterations higher) when the number of processors
>> >> increases.
>> >> >
>> >> >> Is there any options one can use to eliminate this problem?
>> >> >>
>> >> >> Are there any particular solvers which will yield same
>> >> >> convergence regardless of the number of processors?
>> >> >
>> >> > Yes, but they are not good ones to choose: use no
>> preconditioning or
>> >> > just diagonal scaling. But you're likely to find the wall clock
>> >> > time increases over letting the number of iterations increase.
>> >> >
>> >> > -Randall Bramley
>> >> >
>> >>
>> >> _______________________________________________
>> >> 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
>>
>
>
>
More information about the Trilinos-Users
mailing list