[petsc-users] external solvers

[Barry Smith]

On Feb 25, 2010, at 7:19 AM, Umut Tabak wrote:

>
>> Note that shifting changes the matrix so you should always check
>> residuals, and wrap it in an iterative method when you are getting  
>> the
>> wrong solution due to the shift.
>>
>>
> Dear Jed,
> Thanks for the swift reply.
>
> I am not sure I understood this, my main problem was due to the  
> badly conditioned matrices where the convergence was really too slow  
> for the iterative methods, cg especially. Then I just came up with a  
> paper where they are comparing some iterative methods and direct  
> solvers from HSL(namely, MA57) similar to the ones I have, extracted  
> from commercial FE codes where the conditioning of the matrices are  
> on the order of 10e8 or larger for shell type elements(besides I  
> also need shell type elements in my computations for the moment),

    General purpose iterative methods are likely to be useless for  
this type of problem. How large are the problems you wish to solve? If  
less then a few million I'd stick to direct methods like MUMPS.

   Barry



> but my matrices are worser in condition numbers in comparison to the  
> ones that they extracted. A bit of technical detail.
>
> After I saw these shifting options, -pc_factor_shift_nonzero or - 
> pc_factor_shift_positive_definite, in the trouble shooting, I  
> wondered why this kind of shift can not be applied to make the  
> systems better conditioned, namely, adding on the diagonal
>
> ( A +alpha * I )x = b
>
> in that paper they give references to Manteuffel's two papers, when  
> I saw that name also in the manual pages, a ring belt so that was  
> the story if similar things could be applied or not, I have not  
> checked those papers on incomplete cholesky factorization yet though.
>
> This is what I mean, you transform the system to another one, but  
> how to recover back to the original problem? On paper I am checking  
> how these kinds of tricks might work, but I guess, like applying a  
> preconditioner to a matrix, that is not possible. Your explanation  
> above is not clear to me yet.
>
>> Is the matrix actually singular or just very ill conditioned?  See  
>> the
>> -mat_mumps_icntl_* options (look at the MUMPS user's manual for
>> details).  SuperLU has a similar option, and both have "iterative
>> refinement", which might help.  Finally, depending on your  
>> application,
>> it may be possible to reformulate your problem to have better
>> conditioning.
>>
>>
> Matrices are pretty badly conditioned. Moreover one is singular but  
> to form an operator matrix. I am subtracting another scaled matrix  
> from the singular one. As of,
>
> Operator = Sing_Mat - alpha * Another_Mat ; (alpha is large btw, on  
> the order of e5)
>
> where Another_Mat is also badly conditioned but in theory this  
> should not be singular, can be badly conditioned still though.
>
> Thanks for the pointers.
>
> Best Umut