Note also that there is the concept of "node", which is "dof" modulo block size.
On Wed, 25 Feb 2015 09:57:25 +0100 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 > > 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) > > > 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), > - 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. > > ** 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. I've been just searching for the reason of quadratic scaling of SparsityPatternBuilder with Reals. The reason is: 1. sparsity_pattern.diagonal, sparsity_pattern.off_diagonal are not preallocated thus there's a reallocation from time to time at dense rows. This is easily fixable. 2. dolfin::Set allows only insertion of one element, everytime doing (linear) check whether it is already there; hence quadratic behaviour. This is fixable by a) if Reals are treated differently, for instance not stored explicitly. But this does not seem to be compatible with Garth's suggestion of Reals being not "universal" but "domain" or b) adding dolfin::Set::insert_elements(array_like_type) not doing check for duplicity and give a special treatment to Reals in SparsityPatternBuilder The reason why I'm commenting is that it seems to that Reals probably shouldn't be element dofs so that they explicitly have separate treatment in the algorithms. Warning: There is another quadratic problem with Reals in assembly and I haven't looked into this yet. Jan > > Martin _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
