dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Interesting. We are just about to reimplement the assembly in DOLFIN
for UFC and I've been thinking about adding a common interface for
global tensors.

How about

  virtual void add(const real block[],
                   const unsigned int * const * dofs,
                   const unsigned int * num_dofs) = 0;

?

dofs[i] would correspond to the same name in the UFC interface and
rank is not needed since the GenericTensor object knows its rank.

What about initialization? We need to be able to specify the nonzero
pattern of the tensor (matrix).

/Anders


On Thu, Dec 21, 2006 at 10:54:26AM +0100, Martin Sandve Alnæs wrote:
> Since UserMatrixFactory has one central assembly routine for both
> matrices and vectors (and general tensors), I'd like generic vectors
> and matrices to inherit a common interface. It would need the
> functions:
> 
> class GenericTensor
> {
> public:
> // this is generalized:
>  virtual void add(...) = 0;
>  virtual void add(const real block[], unsigned int rank,
>      const unsigned int *const * loc2glob,
>      const unsigned int *dof_map_dim) = 0;
> // perhaps with better names for the last two arguments
> 
> // these are already equal in dolfin::Generic*
>  virtual void zero() = 0;
>  virtual void apply() = 0;
> };
> 
> Here add(...) would be the same as
>  vec->add(block, loc2glob[0], dof_map_dim[0]);
>  mat->add(block, loc2glob[0], dof_map_dim[0], loc2glob[1], dof_map_dim[1]);
> 
> 
> An objection to the dolfin::GenericVector:
>  void init(int N)
> won't work well with Epetra in a parallell setting, so it's not
> completely general.
> 
> 
> martin
> 
> 
> On 11/29/06, Anders Logg <logg@xxxxxxxxx> wrote:
> >I have attached the interface specifications for GenericMatrix and
> >GenericVector for reference (so you don't need to dig them out from
> >DOLFIN).
> >
> >Some of the things in the interface could be discussed.
> >
> >We have just put in the minimal set of functions needed to do
> >assembly.
> >
> >/Anders
> >
> >
> >On Tue, Nov 28, 2006 at 11:19:46PM +0100, Ola Skavhaug wrote:
> >> Anders Logg skrev den 28/11-2006 f?lgende:
> >> > Considering the interface, maybe you could look at the interface class
> >> >
> >> >     GenericVector
> >> >
> >> > in DOLFIN. We have a GenericVector and GenericMatrix interface that is
> >> > satisfied by both our uBLAS and PETSc linear algebra. It would be
> >> > beneficial if we could adopt the same interface.
> >> >
> >> > Of course, I'll be willing to modify the interface for DOLFIN as well.
> >> >
> >> > /Anders
> >>
> >> Excellent idea, Anders. We should make the basic types of PyCC similar 
> >to what
> >> used in DOLFIN.
> >>
> >> Ola
> >>
> >> > On Tue, Nov 28, 2006 at 04:49:53PM +0100, Åsmund Ødegård wrote:
> >> > > Hi dear list,
> >> > >
> >> > > I have now updated the Refcount stuff in PolyRCObj. All my sandbox
> >> > > tests yields the results I want, and I have nailed a couple of
> >> > > serious bugs, so I think it is ready for more general consumption.
> >> > >
> >> > > I will proceed as follows:
> >> > >
> >> > > 1. Implement a better refcounted vector type as an alternative way of
> >> > > feeding numpy arrays into C++ code.
> >> > >     - I am open for input regarding api for this vector type (and
> >> > > even name, right now it is pycc::Vector<T,rcT>). I'm thinking
> >> > >       *) basic constructor
> >> > >       *) copy constructor (operator = ?)
> >> > >       *) constructor based on size and data, and optionally a
> >> > > PyObject* (the numpy; Vector can be used also without python 
> >coupling)
> >> > >       *) get/set operators
> >> > >       *) probably a few more
> >> > >
> >> > > 2. Implement the typemap that transform a numpy array into a
> >> > > refcounted vector when passing through the swig layers
> >> > >
> >> > > During 1. and 2., implement unit tests and write documentation.
> >> > >
> >> > > Basically, the hard work is done, the rest should be walk in the 
> >park!
> >> > >
> >> > > mvh,
> >> >
> >>
> >
> >
> >
>