A few comments on Trilinos: 1.) Teko is fairly new, but promising and in similar spirit to FieldSplit. I have a student planning to start using Teko to work with some people at Sandia on block preconditioning within Trilinos.
2.) At least as of PP14 this year, Bill Spotz was giving a talk on PyTrilinos. I don't think this is super-active, but it's "not dead yet". Regarding keeping it versus not, there are really two levels of support FEniCS could offer for a backend: - "fill support" -- we fill a matrix of this form, and then you're on your own to program this via its native C++/Python interface - "interface support" -- we wrap it so that it conforms all the way to the full DOLFIN interface. It sounds like there is some demand for Trilinos but mainly among people who want to program Trilinos itself rather than just have some warm feelings knowing that deep down inside FEniCS it's using Trilinos. If there is not enough manpower to keep it lockstep to the DOLFIN interface, would providing "fill support" be a compromise that kept people going with Trilinos but reduced the overhead of maintaining it? If this approach worked, it could be a way to migrate Tpetra in (there are issues with thread-parallel filling that would need to be addressed inside dolfin::assemble if one wanted a many core device). Best, Rob ________________________________________ From: [email protected] [[email protected]] on behalf of Phil Weir [[email protected]] Sent: Tuesday, May 27, 2014 6:34 AM To: [email protected] Subject: Re: [FEniCS] Trilinos backend 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 _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
