Based on the comments on this thread, and some updates/comments I
received in another context on Trilinos developments, I propose:
1. The existing Trilinos backend implementation be removed.
2. If/when someone is willing, the Trilinos backend be re-implemented
based on new Trilinos libraries, i.e.Tpetra, MueLu (ML replacement),
etc.
Garth
On Tue, 27 May, 2014 at 1:29 PM, Kirby, Rob <[email protected]>
wrote:
> 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
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
