[Trilinos-Users] Starting out suggestions
Heroux, Michael A
maherou at sandia.gov
Fri Dec 31 09:18:34 MST 2010
Luke,
Just a few more comments:
* I am not sure why you are getting the error message below. A quick search with google shows a lot of hits on the basic error string. Most appear to have something to do with an incomplete compiler environment. Can you compile a basic C program? Might you be using the C++ compiler for C files? The file you are having trouble with is not a common source of errors.
* Regarding iterative vs. direct, direct solvers can be competitive at O(1M) equations, but it depends on the graph connectivity of the sparse matrix. In PDEs, if the underlying domain is 1D, 2D or “2.5D”, direct methods can be effective (where 2.5D is something like a shell element problem in structures). Direct solver buckled under the strain of nonzero fill for true 3D problems of O(1M) or so, although the cross-over point really varies.
* For iterative approaches, because you are solving for so many right-hand-sides, you will want to invest in building a very good preconditioner to keep the iteration costs down, and look at the recycling methods in Belos (at least as a second phase optimization).
* If you have multiple simultaneous RHS, you have further options: You can use the block Krylov methods in Belos and solve for a chunk of the RHS simultaneously (maybe O(10) RHS at once?).
* I can’t think of anything specific that can be done to exploit the fact you have sparse RHS vectors. For sparse operators, we can use multicoloring to reduce the number of operator applications, but that won’t work here. There is obviously some opportunity to reduce the cost of triangular solves with sparse vectors, but I doubt that this will buy you much, since for direct methods the forward solve is already very cheap and for iterative methods the vector will fill in quickly in the early iterations.
Mike
On 12/30/10 4:50 PM, "Luke Bloy" <lbloy at seas.upenn.edu> wrote:
Hi Mike,
thanks for the response. I have a couple of follow up questions.
For the belos/Eperta/Ifpack path i came across the PrecGCRODREpetraExFile example. Does this seem like a reasonable place to start?
On a more basic level. I'm not 100% sure what I gain using the iterative solvers over the direct solvers available via amesos. I assume that the iterative solvers are less memory intensive but beyond that i'm not positive what is gained by using the more complex methods.
When I'm compiling with amesos turned on, via the ccmake interface (I'm going to try to duplicate the problem from a cmake script). I get the following compilation error.
/opt/trilinos-10.6.2-Source/packages/amesos/src/SuiteSparse/CHOLMOD/Core/amesos_t_cholmod_dense.c:23: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
Whats is the preferred method to submit a bug report?
Thanks again for the help.
Luke
On 12/30/2010 02:38 PM, Heroux, Michael A wrote:
Re: [Trilinos-Users] Starting out suggestions Luke,
You have figured out quite a bit already. Very good.
There are several choices you can make going forward. Here are some options:
* Yes, converting from the ublas to Epetra is the first required step. As an alternative, you might consider trying Tpetra. Although newer, more complicated and having a few know performance disadvantages vs. Epetra, Tpetra provides compilation targets for multicore and GPUs, supports multiple floating point and integer types and is where most of the manycore research in Trilinos is occurring. However, using Epetra first is not bad, even if you might be interested in
Tpetra eventually, since they have very similar APIs.
* Ifpack is a good choice for preconditioning options, but has a similar counterpart as Epetra, called Ifpack2. Ifpack2 is based on Tpetra and is again where all of the manycore and multiprecision work is going. Once again, switching to Ifpack2 later should be fairly straight-forward. We have two iterative solver packages: AztecOO and Belos. Similar to the above discussion, AztecOO is based on Epetra solely. Belos supports both Epetra and Tpetra, and can support multiprecision.
* Stratimikos is a good option to manage the use of preconditioners and iterative solvers. It allows easy switching between AztecOO and Belos, and preconditioner packages Ifpack and ML. It will eventually support Tpetra and Ifpack2, but doesn’t right now.
*
So, the general advice:
For best MPI-only performance today with a robust double-precision-only and mature software stack, you can use Epetra with AztecOO (or Belos), Ifpack and ML (which is necessary for scalability eventually). You can use the solvers and preconditioners via Stratimikos, which is very convenient.
For future oriented software development, the Tpetra/Belos/Ifpack2 option is viable.
I hope this helps.
Mike
On 12/30/10 12:10 PM, "Luke Bloy" <lbloy at seas.upenn.edu> wrote:
> Hi,
>
> I'm new to trilinos and am looking for some suggestions on where to start.
>
> My immediate application is to repeatedly ( 10,000 - 500,000 times)
> solve a sparse linear system defined by a non-symmetric matrix A. The
> size of A is roughly 2,000,000 square but with only ~ 30,000,000
> unknowns. The RHS of these systems will also generally be fairly sparse.
>
> In my head the procedure would be.
> 1) Convert ublas csr matrix to Eperta format.
> 2) compute an ILU or other preconditioner (ifpack)
> 3) then solve each RHS
>
> I've just begun to go through the tutorials and documentation. At first
> if seemed I should be looking at Belos and ifpack or perhaps Amesos. but
> then I came across Stratimikos and thought that looked promissing.
>
> So i guess my question is where should i start?
>
> Thanks in advance.
> Luke
>
>
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://software.sandia.gov/pipermail/trilinos-users/attachments/20101231/556dfe3f/attachment.html
More information about the Trilinos-Users
mailing list