dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 31, 2008 at 01:49:08PM +0200, Martin Sandve Alnæs wrote:
> 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.

I agree, I also wouldn't want to touch this if Kent is simultaneously
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.

We just need to decide whether or not we want *any* functions to
*ever* check the type of a GenericVector. It would be good to avoid
it.

I guess the problem might be the implementation of mult()? Maybe this
should not be in the GenericFoo interface, since it's difficult to do
through the interface.

-- 
Anders