On 25 February 2015 at 13:14, Garth N. Wells <[email protected]> wrote:
> 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? > In a multi-mesh scenario the 'domain dofs' would be associated with (a subset of) one mesh while universal dofs are fully mesh-independent. How do you propose associating domain dofs with subdomains? We would need some sort of stronger definition of subdomain ids. Should the subdomains in this context be arbitrary subsets of cells? Related to a particular set of cell markers? Related to the subdomain ids in integration measures? It would be a lot simpler if we just had mesh-independent reals... Martin 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
