On Wed, Feb 25, 2015 at 12:27 PM, Martin Sandve Alnæs <[email protected]> wrote: > 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? >
I have in mind at this stage applications rather than details of an implementation. A simple application is a Lagrange multiplier that lives on a subset of the boundary. Another example is a problem with Stokes in part of the domain and another equation elsewhere. I might want a 'Real' to live only on the Stokes part of the domain, and would like to know this so I can re-order dofs on the different domains independently. I did have in mind that MeshViews would be pretty central to this all. Garth > 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
