On Tue, 27 May, 2014 at 12:07 PM, Nico Schlömer
<[email protected]> 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.
With the upcoming changes in Trilonos (Teptra, new replacement for ML)
maybe it's ready for a re-write? This could be done by removing the
current wrappers and starting from scratch.
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*.
I don't have any plans to remove the uBLAS functionality (although I
think it would be good switch to Eigen wrappers rather than uBLAS, now
that Eigen is a dependency).
The overhead in maintaining the serial backends in minimal. The
headache is the parallel backends, especially around issues like
managing ghost entries, differences in how off-process vector/matrix
are set.
Garth
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
