On 25 February 2015 at 10:22, Garth N. Wells <[email protected]> wrote:
> On Wed, Feb 25, 2015 at 8:57 AM, Martin Sandve Alnæs <[email protected]> > wrote: > > I've started working on this issue: > > > https://bitbucket.org/fenics-project/ffc/issue/61/global-dofs-aka-reals-should-not-be > > > > Can we agree on a target convention for naming of dofs in FEniCS? > > I'd like to clean it up, and in the process get to know > > the current dofmap implementation in dolfin better. > > > > Here's my suggestion for terminology: > > > > global dof numbering = numbering of dofs globally agreed upon across all > > processes > > local dof numbering = numbering of dofs local to a single process (*) > > element dof numbering = numbering of dofs local to a single finite > element > > entity dof numbering = numbering of dofs local to a single mesh entity > > > > There is a subtle difference between 'element dof numbering' and > 'entity dof numbering' in the implementation. At present, 'element dof > numbers' are the local (process-wise) indices, and 'entity dof > numbers' and element-wise (local to the element). > That would be the 'local dof numbering of the element dofs' and the 'element dof numbering of the entity dofs' in the terminology I'm trying to communicate here. The current implementation names should be cleaned up to match what we agree on. One key point is to make clear the distinction between sets of conceptual dofs and their labels from various perspectives. I.e. 'the element dofs of element k' and 'the entity dofs of entity (d,i)' are both sets of dofs that can be labeled by multiple numbering schemes. I'll make pull requests for eventual naming changes I do. > global dofs = all dofs > > local dofs = all dofs on a single process > > element dofs = all dofs associated with a particular element (including > its > > subentities) > > entity dofs = all dofs associated with a particular mesh entity (not > > including its subentities) > > facet dofs = dofs associated with a particular facet including its > > subentities > > universal dofs = dofs not associated with any mesh entity (constants, the > > "Real" space) > > > > I'm not too keen on the name 'universal dofs'. We want these dofs > belong to a (sub)-domain. Maybe 'domain dofs'? > Do we? What's the advantage? It seems to me that the machinery needed for handling constants varying with the (sub-)domain is overkill when the user can just use different globally defined constants in different parts of the forms. But I don't mind 'domain dofs'. We can use that name initially without any subdomain selection until we see a concrete need to add that. > So for example a dof associated with a vertex (0,i) is part of: > > - the 'facet dofs' of facets (d-1,j) adjacent to vertex (0,i), > > - the 'entity dofs' of vertex (0,i), > > - the 'element dofs' of cells (d,k) adjacent to vertex (0,i), > > - the 'local dofs' of the process that owns this dof, > > - and the 'global dofs', unconditionally. > > > > The new part here is the concept of a 'universal dof' which is part of: > > - the 'element dofs' of all cells (**this is disputable), > > This should be 'an arbitrary number of cells/entities' rather than 'all > cells'. > True if we end up implementing domain dofs associated with subdomains, which I think we may avoid but we'll see what we end up with when we get there. I'll begin with adding domain dofs without a domain association, then we can extend it later if needed. > - the 'local dofs' of the process that owns this dof, > > - and the 'global dofs', unconditionally. > > However the universal dof is NOT part of any entity dofs or facet dofs. > > > > * It's not clear to me whether local dofs include ghosted dofs or not. > > > > Depends on how one defines 'local dofs'. If local dofs are all dofs in > the dofmap on a process, then yes they're local. If local dofs are > those that have been numbered by the process, then the ghosts are not > local. > > From a high level, I think it's better to think of dofs maps as > overlapping. The question of 'ownership' only comes up when > initialising the data structures for some linear algebra backends. > > For this reason, I have been planning to deprecate > GenericDofMao::ownership_range() now that dofmaps use process-wise > indices. > Ok. From the UFC/FFC point of view it doesn't matter, so I can go ahead adding 'domain dofs' and see if I can clean up some naming related to 'cell dofs' and 'element dofs'. Martin > Garth > > > ** The universal dof needs to be part of the element dofs at least for > the > > time being, unless we change a lot of code and handle them separately. > > For constants that would be fine (and better in a lot of ways), but for > > mixed > > elements with a Real subspace that's trickyer. > > > > Martin > > > > _______________________________________________ > > fenics mailing list > > [email protected] > > http://fenicsproject.org/mailman/listinfo/fenics > > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
