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. -- Anders _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
