dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 10, 2008 at 09:44:18PM +0200, Martin Sandve Alnæs wrote:
> 2008/4/10, Anders Logg <logg@xxxxxxxxx>:
> > 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