[Trilinos-Users] Block versions of Trilinos preconditioners

[Heroux, Michael A]

Hello Dmitry,

I will answer your questions below.

Mike


On 9/14/09 3:50 PM, "I-Kamenetskiy, Dmitry S" <dmitry.s.kamenetskiy at boeing.com> wrote:

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).

There are no production-quality block preconditioners that take advantage of the Epetra_VbrMatrix block structure.  At one point we had developed these but they were not competitive with point-oriented preconditioners on problems of interest.  Basically our experience was that the ability of the point preconditioners to select point-by-point which entries to keep was more effective use of non-zero storage than requiring a block-by-block selection, even though the block preconditioners were more efficient at computation.

Thus preconditioners for Epetra_VbrMatrix access values row-by-row and construct point-wise preconditioner.

This is an issue we will revisit in the near future with Tpetra where we use template parameters to represent the scalar type.  Since we can use a dense matrix as the scalar type, it is possible to support block preconditioning without additional work.

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.

The issue with using Epetra_VbrMatrix as an Epetra_RowMatrix is a known problem and was supposed to be fixed by the introduction of the Epetra_VbrRowMatrix.  If you can give me more details on your situation, or can send a small test case to me directly, please do.


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.

AztecOO uses right preconditioning only.  This is a low-hassle approach since it does not introduce changes in the residual computations.

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