dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Thu, Apr 10, 2008 at 9:15 AM, Jed Brown <fenics@xxxxxxxx> 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.

And PETSc supports umfpack, --download-unfpack.

  Matt

>  Jed
>  _______________________________________________
>  DOLFIN-dev mailing list
>  DOLFIN-dev@xxxxxxxxxx
>  http://www.fenics.org/mailman/listinfo/dolfin-dev
-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener