dolfin team mailing list archive

[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