dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 31, 2008 at 02:05:25PM +0200, Ola Skavhaug wrote:
> Anders Logg skrev den 31/03-2008 følgende:
> > 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.
> 
> That is the problem in having a simpler design, omitting the Matrix-wrapper
> construction, and using only a typedef? F.ex.
> 
> typedef Matrix uBlasMatrix;
> 
> If we are consistent in the DOLFIN library, only communicating GenericFoo
> across the interfaces, the chances of non-compatible code being propagated
> into the library is minimal. The only place the additional methods of a
> particular backend can be used is in user space (and hence not our
> concern).
> 
> This will give the nice syntax Anders wants, and conforms with standard
> oo-design. The cost is that methods added to a backend will be accessible
> through the Matrix typedef, and this might lead to non-portable _user_ code.
> 
> ??
> 
> Ola

Yes, the problem with what we had before, namely

  typedef FooMatrix Matrix;
  typedef FooVector Vector;

was that it allowed writing code depending on Matrix and Vector which
was not portable (when changing the typedef).

For example, it was fully possible to do

  Matrix A;
  MatSetValues(A.mat(), ...);

but this wouldn't work unless DOLFIN was compiled with

  typedef PETScMatrix Matrix;

So, the purpose of the current design with a class Matrix inheriting
from GenericMatrix and having a FooMatrix pointer is to make sure that
Matrix can only do the things defined in GenericMatrix, nothing less
(which is handled by the compiler) and nothing more (which we must
take care of manually).

-- 
Anders