← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] merge

 



Anders Logg wrote:
On Tue, Sep 08, 2009 at 04:12:45PM +0200, Garth N. Wells wrote:

Anders Logg wrote:
On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
Johan Hake wrote:
On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.

changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
tag:         tip
parent:      6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
parent:      6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
user:        Anders Logg <logg@xxxxxxxxx>
date:        Tue Sep 08 12:51:01 2009 +0200
files:
description:
merge


changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
parent:      6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
user:        Anders Logg <logg@xxxxxxxxx>
date:        Tue Sep 08 12:01:43 2009 +0200
files:       dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
description:
Make tabulate_facet_dofs accessible without having a ufc::cell, which
makes it easy to access using iterators in Python.
Can we remove the version that takes a ufc::cell?
Yes. Perhaps we should remove all the direct wrappers for UFC stuff
and add a member function to return the underlying UFC object?

  const ufc::dof_map& ufc_dof_map() const;
Should this be a member function of dolfin::DofMap? If so, it might be
sufficient with

  const ufc::dof_map& ufc() const;
Definitely not! The whole point of DofMap is to not expose ufc::dof_map
in DOLFIN. It took a lot of work some time ago to fix this. Using
ufc:dof_map screws up any dof renumbering.
There shouldn't be any problem allowing access to the underlying UFC
objects. We do the same thing for PETSc with mat() and vec() and a
user has just as big a chance to screw things up there.

The problem with ufc objects is that developers screw things up too.
I've spent a lot of time fixing this. Permitting access to the
ufc::dof_map through DofMap defeats the purpose of having DofMap. I
can't see any reason for allowing access to the ufc::dof_map from DofMap.

Garth

I don't use it, but I don't see the difference between this and our
PETSc and Trilions wrappers.


There is a big difference. PETScFoo and EpetraFoo objects are always based on an underlying PETsc or an Epetra object. A DofMap can be initialised with a ufc::dof_map, after which the DofMap and the ufc::dof_map are more or less unrelated, for example after renumbering. Providing access to the ufc::dof_map encourages its use, which is fine as long as nothing is renumbered, but causes problems when the dof map is renumbered, like when running in parallel. This is why ufc::dof_map should not be be exposed anywhere in DOLFIN. This includes ufc::dof_map related functions, like DofMap::offset, which has been removed.

Garth

Anyway, it's not a big deal and it's easier to not add it so let's
keep it the way it is but modify the interface where appropriate so it
assumes dolfin::Cell instead of ufc::cell etc.

--
Anders


------------------------------------------------------------------------

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev




Follow ups

References