dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Sep 08, 2009 at 05:00:37PM +0200, Garth N. Wells wrote:
>
>
> 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

Good point. I see the difference now.

--
Anders


> > 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.
> >
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature