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