We might actually want to have both 'domain dofs' (which I don't know how to identify with domains in ufc yet) and 'universal dofs' (without a domain association).
To optimize the assembly, I think I can arrange generation of code to compute the blocks of the element matrix with uflacs. Then the dense blocks can be handled separately. Martin On 25 February 2015 at 12:39, Jan Blechta <[email protected]> wrote: > 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
