dolfin team mailing list archive

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

On 1/17/07, Anders Logg <logg@xxxxxxxxx> wrote:
> On Wed, Jan 17, 2007 at 08:43:04AM +0100, Martin Sandve Alnæs wrote:
> > On 1/16/07, Garth N. Wells <g.n.wells@xxxxxxxxxx> wrote:
> > > Martin Sandve Alnæs wrote:
> > > > But if we are to merge the projects it would be nice to know as soon as
> > > > possible, to avoid wasting time on duplicated code.
> > > >
> > >
> > > I don't see a problem with two codes as it gives each project the
> > > freedom to pursue different interests/goals/visions. It gets complicated
> > > when a lot of developers get involved. It would/will be nice if/when
> > > PyCC is opened up so we can look at each others work, exchange ideas and
> > > code, and collaborate more.
> >
> > True. I think keeping two separate Assembler projects while
> > collaborating is the best plan, to avoid too strong dependencies.
> >
> > martin
>
> I agree, let's have two separate assemblers for a while. But let's set
> up a set of benchmarks that we can run with both codes to learn how to
> do things best.
>
> We need to choose a set, say 3-4 different combinations, of
>
>      (form, mesh, repetitions)
>
> and then measure the CPU time (wall-clock time) for assembling the
> sparse tensor (matrix).
>
> Suggestions?

The forms should at least include a simple mass matrix, such that the
element tensor computation is not dominating, and something with many
coefficients, so efficient coefficient handling is tested.

The target matrix format (petsc, epetra, pycc.crs, etc) should also be
a parameter. And perhaps dofmap properties, like numbering scheme?

martin