dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 31, 2008 at 02:47:30PM +0200, Ola Skavhaug wrote:
> Anders Logg skrev den 31/03-2008 følgende:
> > 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).
> 
> I understand this. My point is that if we use GenericFoo consistently though
> the interface of DOLFIN, the (mis)use of Matrix will only live in user code.
> 
> Ola

Do mean that we don't need the Matrix and Vector classes, that we can
use typedefs instead since we will only break someone else's code, not
our own?

-- 
Anders