[Trilinos-Users] [EXTERNAL] Re: MueLu setting block size warning (Tpetra+Belos+MueLu)
Wiesner, Tobias Albert (-EXP)
tawiesn at sandia.gov
Tue Apr 25 17:59:56 EDT 2017
Andrey,
we certainly could do a better job or make the warning (or printout) more verbose.
I think we can distinguish the following scenarios:
1) The user creates the Xpetra::Matrix by hand and also sets the block size. Then, the warning would make sense if the user (accidently) overwrites the block size by a leftover "number of equations". That is, there should probably be a warning if blockSize in the matrix is > 1 and different to what is set in the xml file. Maybe there should be always a warning if the block size stored in the Xpetra::Matrix differs from what is set in the solver parameters. Not sure how easy this is. I guess "number of equations" is validated and the default is 1. So, if the user does not set it in the parameter list, we might want to ignore it (no warning, just printout?)
2) I think it is simpler if the user uses the Create{E,T}petraPreconditioner interface. Since Epetra_CrsMatrix and Tpetra::CrsMatrix have no notion of a block size, the user HAS to set it by hand in the parameter list ("number of equations"). A standard printout (instead of a warning) would probably be sufficient.
However, the Create{E,T}PetraPreconditioner routines call the general routines in CreateXpetraPreconditioner which would trigger the warning. So i am not fully sure what the best logic would be.
I think you are right: if we switch from scalar to block: just do printout
If we have some kind of block operator and the parameter "number of equations" is set (to something different) then throw a warning.
Did i forget something?
Tobias
________________________________________
From: Prokopenko, Andrey V. <prokopenkoav at ornl.gov>
Sent: Tuesday, April 25, 2017 13:36
To: Granzow, Brian N (External Contacts); trilinos-users at trilinos.org; Wiesner, Tobias Albert (-EXP); muelu-developers
Subject: [EXTERNAL] Re: [Trilinos-Users] MueLu setting block size warning (Tpetra+Belos+MueLu)
Hi Brian,
This is a minor warning, and it does not pose a problem in this case. It
simply indicates that after your original operator was converted to
Xpetra object (Xpetra matrix, specifically) that matrix was still
considered scalar on the input. You did the right thing by indicating
the number of equations, and this warning means that from now on we are
going to treat a scalar matrix as a block matrix.
Tobias,
We could certainly do a better job on phrasing the warning and finding a
situation where it is necessary. When do we really want this to be a
warning, and when a simple Runtime0? I feel like if we switch from
scalar to block matrices through a provided "number of equations", it
should not be a warning. But I also recall that there was history behind
this.
-Andrey
On 4/25/17 1:49 PM, Brian Granzow wrote:
> Hello!
>
> I have an application that uses Tpetra + MueLu + Belos to solve linear
> systems obtained via finite element assembly. To create the MueLu
> preconditioner, I am using the function:
> MueLu::CreateTpetraPreconditioner:
>
> https://github.com/trilinos/Trilinos/blob/master/packages/muelu/adapters/tpetra/MueLu_CreateTpetraPreconditioner.hpp#L49
>
> I am passing this function the required Tpetra::Operator (inA) and
> input Teuchos::ParameterList (inParamList), as well as the optional
> coordinate Tpetra::MultiVector (inCoords). For a problem with 3
> degrees of freedom per node (linear elasticity), I specify the MueLu
> input parameter "number of equations" to be equal to 3, and I see the
> warning below:
>
> ```
> ******* WARNING *******
> Setting matrix block size to 3 (value of the parameter in the list)
> instead of 1 (provided matrix).
> You may want to check "number of equations" (or "PDE equations" for
> factory style list) parameter.
> ```
>
> I am curious if anyone has experienced this before, and if the fix is
> immediately obvious.
>
> ---
>
> For more detail, the Tpetra::Operator (inA) that is passed to
> MueLu::CreateTpetraPreconditioner by dynamically casting an existing
> Tpetra::CrsMatrix to a Tpetra::Operator. The coordinate
> Tpetra::MultiVector is constructed from a Tpetra::Map that describes
> the parallel local to global distribution of nodes (in this case mesh
> vertices). The distinction here being that the number of rows of the
> coordinate MultiVector is smaller than the number of rows of my
> Tpetra::CrsMatrix by a factor of 3 (since there are 3 degrees of
> freedom per node). In fact, I've used this exact same approach in a
> small application in Albany where I did not see the above warning:
>
> https://github.com/gahansen/Albany/blob/master/src/CTM/CTM_LinearSolver.cpp#L50
>
> My current application is nearly identical to this Albany application,
> so I'm unsure where I am going wrong. I am pretty confident that the
> Tpetra::Operator is formed correctly as I am able to solve my FEM
> problem with correct results when I simply omit passing the coordinate
> vector to MueLu::CreateTpetraPreconditioner and leave the "number of
> equations" parameter as the default value.
>
> Thanks for the consideration,
> Brian Granzow
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at trilinos.org
> https://trilinos.org/mailman/listinfo/trilinos-users
>
More information about the Trilinos-Users
mailing list