On Wed, Feb 25, 2015 at 12:07 PM, Martin Sandve Alnæs <[email protected]> wrote: > 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). >
Wouldn't these 'universal dofs' be associated with the entire domain? Garth > 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 > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
