[Trilinos-Users] Block versions of Trilinos preconditioners

[I-Kamenetskiy, Dmitry S]

Hello,

 

I am interested in using Trilinos preconditioners with the jacobian matrices (in Newton method) which are assembled as Epetra_FEVbrMatrix objects --- with small constant block size (4,5,6) corresponding to the number of PDEs in a grid point. While Trilinos Epetra classes do reasonable work for these matrices at the assembly stage, I have some misunderstanding and difficulties when using Trilinos preconditioners for them.

 

1) My first question is rather general.

What are the preconditioners within Trilinos packages (AztecOO, IFPACK, ML) which actually make use of the Epetra_VbrMatrix block-entry structure.

More precisely, I mean to ask what preconditioners (if existent) basically do exact inversions of the Epetra_SerialDenseMatrix entries.

 

Related question is: as it is common to the preconditioners in Trilinos to treat sparse matrices of linear systems via the Epetra_RowMatrix interface does it mean that the sparse block matrices will essentially be treated by these preconditioners as the scalar sparse matrices? I judge from the Epetra_RowMatrix interface description which basically allows to retrieve copies of scalar rows (not block-entry rows).

 

2)  This question is rather special and technical.

 

For the linear system matrix in Epetra_VbrMatrix format:

when using IFPACK Additive Schwarz preconditioner with Overlap>0 I get the following error message

 

> Epetra ERROR -3, ../../../.././packages/epetra/src/Epetra_DistObject.cpp, line 110 

 

I experimented a bit with the Trilinos source code and found out that the message is generated by the 

following assertion being violated (just in the beginning of int Epetra_DistObject::Import() method) :

 

  if (!Map_.SameAs(Importer.TargetMap())) EPETRA_CHK_ERR(-2);

  if (!A.Map().SameAs(Importer.SourceMap())) EPETRA_CHK_ERR(-3); // Violated

 

This in case is caused by the Import() call from the Ifpack_OverlappingRowMatrix(...) constructor (file: IfpackOverlappingRowMatrix.cpp)

 

102                 TmpMatrix->Import(A(),*TmpImporter,Insert);

 

It turns out in this case that the Epetra_CrsMatrix TmpMatrix (constructed with overlap from original matrix A() ) has scalar map while the original one has block map. Again, by experimenting with source code in IfpackOverlappingRowMatrix.cpp I found out that the first assertion below is false (and this is what is being checked in Epetra_DistObject.cpp ) while the second one evaluates to true:

 

              assert( Matrix_->Map().SameAs( TmpImporter->SourceMap()) );          // false

              assert( Matrix_->Map().PointSameAs( TmpImporter->SourceMap()) );   // true

 

To me it seems like a bug in the implementation (though I can not be 100% sure, of course). 

 

Anyway is there any way to the Epetra_VbrMatrix type matrices to be used in IFPACK Additive Schwarz preconditioner with non-zero overlap?

 

I tried to wrap the Epetra_Vbrmatrix'es I build into the Epetra_VbrRowMatrix object before passing in to the linear system --- unfortunately this did not resolve the above problem. On the other hand, compared to that, the internal AztecOO AZ_dom_decomp preconditioner with non-zero overlap does not have any problems with the Vbr matrices.

 

 

3) If anyone had patience to read up to this point, here is a kind of naïve question:

 

In AztecOO linear system solvers what is the default side of preconditioning (left or right?). Is it any way to change the side system is preconditioned (I mean, in AztecOO; I know I can do this in Belos). Strangely enough by traversing the Aztec/AztecOO documentation I was not able to find any reference on this subject.

 

Thank you,

 

Best regards,

 

Dmitry Kamenetskiy

 

Boeing Commercial Airplanes

CFD Development & Geometry

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://software.sandia.gov/pipermail/trilinos-users/attachments/20090914/e4ed7ff3/attachment.html