Ola Skavhaug wrote: > Anders Logg skrev den 11/04-2008 følgende: >> On Thu, Apr 10, 2008 at 09:44:18PM +0200, Martin Sandve Alnæs wrote: >>> 2008/4/10, Anders Logg <[EMAIL PROTECTED]>: >>>> On Thu, Apr 10, 2008 at 04:15:31PM +0200, Jed Brown wrote: >>>> > On Thu 2008-04-10 12:14, Ola Skavhaug wrote: >>>> > > To be able to tackle solvers through the Generic* interface, should we >>>> > > consider having a GenericSolver? Today, a LUSolver has a >>>> DefaultLUSolver, a >>>> > > typedef to either uBlasLUSolver or PETScLUSolver. Not clear to me >>>> what the >>>> > > best solution is... >>>> > >>>> > I've been watching this discussion for a while and it seems to me that >>>> the >>>> > direction this is going is a duplication of the PETSc Mat/KSP/PC >>>> abstraction. >>>> > In my opinion, anything less would become frustrating down the line. >>>> Of course, >>>> > if you don't want to always depend on PETSc, you have to duplicate the >>>> > abstraction. This can be done in a more C++ native way, but it will >>>> end up >>>> > looking quite similar and being a fair amount of work. It's not clear >>>> to me if >>>> > the reason to avoid a hard PETSc dependence is desire for a stronger >>>> direct >>>> > solver than the default, or that you really don't want users to need to >>>> install >>>> > it. If it's the former, building with Umfpack seems like a decent >>>> solution. >>>> > The power of being able to try out different solvers on the command >>>> line is >>>> > extremely useful in my experience. >>>> > >>>> > Jed >>>> >>>> >>>> The reason not to depend on PETSc is that we want to be able to change >>>> the backend (for many reasons). In particular, we want a user of DOLFIN >>>> to be able to plug in her/his own backend. For example, PyCC uses its >>>> own implementation CRSMatrix which inherits from GenericMatrix and >>>> which may thus be used directly with DOLFIN. People have also reported >>>> using their own implementations of higher-order tensors and assembling >>>> into those directly using the DOLFIN assembler. >>>> >>>> -- >>>> >>>> Anders >>> The main point is to have interfaces for assembly into general linear >>> algebra backends, the rest is convenience stuff built on top. >>> >>> If we were to add interfaces for linear system solvers, it would have >>> to be because we had higher-level components in DOLFIN that needs a >>> linear system solver as input, but are there any such components? We >>> don't really need a solver interface just to make the "black-box" >>> solve(A,x,b) work with the few built-in backends in DOLFIN. >> I think we can manage without this. > > There are a lot of Solver classes and subclasses in dolfin. Should these be > removed? >
The simpler the better, so if we can remove come, great. Garth > Ola > >> -- >> Anders >> _______________________________________________ >> DOLFIN-dev mailing list >> [email protected] >> http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
