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 <[email protected]> >>>>>>>>> date: Tue Sep 08 12:51:01 2009 +0200 >>>>>>>>> files: >>>>>>>>> description: >>>>>>>>> merge >>>>>>>>> >>>>>>>>> >>>>>>>>> changeset: 6974:6c4c77900222f82b7b32888b29a08fef9ddc5789 >>>>>>>>> parent: 6970:5d7fc35d3e597db508a005826efacb8dea6a00d9 >>>>>>>>> user: Anders Logg <[email protected]> >>>>>>>>> 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 > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
