dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/3/31, Anders Logg <logg@xxxxxxxxx>:
> On Mon, Mar 31, 2008 at 01:11:42PM +0200, Martin Sandve Alnæs wrote:
>  > 2008/3/31, Anders Logg <logg@xxxxxxxxx>:
>  > > On Sun, Mar 30, 2008 at 11:04:57PM +0200, Martin Sandve Alnæs wrote:
>  > >  > 2008/3/30, Anders Logg <logg@xxxxxxxxx>:
>  > >  > > On Sun, Mar 30, 2008 at 10:25:06PM +0200, Martin Sandve Alnæs wrote:
>  > >  > >  > Then solve should be fixed to expect a GenericVector, what's the problem?
>  > >  > >
>  > >  > >
>  > >  > > Yes, but that needs some thinking. The solve() function needs to check
>  > >  > >  what kind of arguments it gets and redirect to the correct backend.
>  > >  > >  For example, if (A, x, b) are PETSc objects, then it needs to call a
>  > >  > >  PETSc solver (which does not work through the GenericFoo interface).
>  > >  > >
>  > >  > >  I guess you can work your magic try { dynamic_cast<...> } here?
>  > >  >
>  > >  > Sure, that should be easy. I'll look at it tomorrow.
>  > >
>  > >
>  > > Fint!
>  > >
>  > >  solve() ligger i dolfin/la/solve.{h,cpp}
>  >
>  > Vector creates problems when testing the type of a GenericVector.
>  >
>  > All code that wants to test the type of a GenericVector
>  > will depend on Vector.
>  >
>  > Do you really want all this type trouble just to be able to write
>  >
>  >   Vector v;
>  >
>  > instead of
>  >
>  >   typedef FooVec Vector;
>  >   ...
>  >   GenericVector *v = new Vector()
>
>
> Yes! "Vector v" looks almost infinitely better than having to write
>  typedefs and calling new.
>
>  But we don't really need to fix solve() if it's too much trouble.
>  If we don't want to dynamically resolve the representation of matrices
>  and vectors, then there will be some functions such as assemble() that
>  work for any type of vector (GenericVector) and there will be others
>  that work only for a specific implementation.
>
>  So, if you have a Vector, then you can use it with everything:
>
>    assemble()
>    solve()
>    LUSolver
>    KrylovSolver
>
>  but if you have a FooVector, then you must use it with the
>  Foo solvers:
>
>    FooLUSolver
>    FooKrylovSolver
>
>  So, if it's too much trouble to resolve the backend dynamically, then
>  we don't really need to do it.
>
>  The basic idea here is that if you don't care about the backend,
>  just use Matrix and Vector and everything is simple (assemble, solve).
>
>  But if you want to use some special backend, then use FooMatrix,
>  FooVector and FooSolver.


Fixing solve won't be a problem, but I don't want to do it while Kent
is messing around with the Vector stuff.

But this is a bigger issue.

This touches all code that needs to check the type of a GenericVector.
All this code must depend on Vector. I previously accepted Vector
because I can ignore it, but because of this it potentially affects
everything.

Also, uBlasVector needs to check the type of its arguments, and thus
we have a circular dependency.

--
Martin