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? 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
