On 05/27/2014 12:07 PM, Nico Schlömer wrote:
The Trilinos backend isn't in a shape as good as PETSc is, and the
same goes for the Trilinos codebase itself and everything surrounding
it ("community managment").
That said, I believe that Trilinos offers a number of things that are
not included in PETSc itself. For example, the variety of linear
solvers included in Trilinos::Belos is quite large,
BlockCG
BlockGCRODR
BlockGmres
GCRODR
GmresPoly
Gmres
LSQR
Minres
PCPG
PseudoBlockCG
PseudoBlockGmres
PseudoBlockStochasticCG
RCG
TFQMR
Not all of them are interfaced by Dolfin, but I suppose this can be done.
Moreover, ML has a number of AMG options that are not available from
other preconditioning packages; one of them is the important class of
AMG for curl-curl problems.
I don't think Trilinos nicely supports Schur complement preconditioners
Trilinos::Teko <http://trilinos.sandia.gov/packages/teko/> is designed
for this purpose. I haven't used it myself though.
That said, my reason for using Trilinos was mainly its nice Python interface,
PyTrilinos is virtually dead.
I think a big selling point of Trilinos is the development that
happens in Trilinos::Tpetra -- it shows great promise in the HPC
arena when computing large problems in heterogeneous environments (for
example). Currently, Dolfin hooks up to (legacy) Epetra, so adopting
this may be worthwhile.
To chime in, since I have been working with Tpetra / Belos / Kokkos /
IfPack2 recently (outside of a FEniCS context). While that has been good
in a number of ways, especially for heterogeneity, there are some things
still to appear, e.g. BiCGStab. However, porting Epetra code to the new
framework has been fine, and I, personally, prefer the more object
oriented approach to PETSc's C, so I'm happy enough to code with it, but
that may not be how the FEniCS developers feel. Also, with Trilinos I
have not needed to work at the level Garth is discussing, so I can see
how maintaining separate approaches to handle ghost cells, etc. could be
a recurring issue.
I do understand Garth's concerns, though, and I don't use the Trilinos
backend too often now. I can see myself in the situation though where
I run Dolfin code in an HPC environment and would like to see what
Trilinos can do for me.
It has been a while since I have looked at PETSc's heterogenous
architecture support, but my memory was that it was not necessarily
behind the new Trilinos/Kokkos framework - is this the case or is
Trilinos actually significantly ahead?
Also, let's not forget about the uBLAS layer which I find
exceptionally useful for debugging purposes. Removing Trilinos alone
would not do away with the abstraction layer Generic*.
Are there other ways of reducing the maintenance burden for the developers?
Cheers,
Nico
On Mon, May 26, 2014 at 5:32 PM, Garth N. Wells <[email protected]> wrote:
Are there any strong opinions on keeping or removing the Trilinos backend
from DOLFIN? I ask now because there is a maintenance burden in having both
(I'm feeling this acutely with the switch to local dof indices), and the
Trilinos backend gets far less polishing and testing than the PETSc backend,
which can make a less favourable impression on users who use the Trilinos
backend.
Another issue is that it is becoming difficult to provide users with a
common interface to more sophisticated solvers since these are closely tied
to the design of the underling linear algebra backend.
Garth
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
--
__________________________
Phil Weir | NUMA Engineering Services Ltd.
The Business Centre, Blackthorn Business Park, Coe's Road, Dundalk, Co.
Louth, Ireland.
Tel: +353 42 9395821 | Fax: +353 42 9390220
_______________________
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
