dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

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

There are a lot of Solver classes and subclasses in dolfin. Should these be
removed?

Ola
 
> -- 
> Anders
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev