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
