On Wed, Feb 25, 2015 at 10:48 AM, Martin Sandve Alnæs
<[email protected]> wrote:
>
> On 25 February 2015 at 10:22, Garth N. Wells <[email protected]> wrote:
>>
>> On Wed, Feb 25, 2015 at 8:57 AM, 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
>> >
>>
>> There is a subtle difference between 'element dof numbering' and
>> 'entity dof numbering' in the implementation. At present, 'element dof
>> numbers' are the local (process-wise) indices, and 'entity dof
>> numbers' and element-wise (local to the element).
>
>
> That would be the 'local dof numbering of the element dofs' and the
> 'element dof numbering of the entity dofs' in the terminology I'm trying
> to communicate here. The current implementation names should be
> cleaned up to match what we agree on.
>
> One key point is to make clear the distinction between sets of
> conceptual dofs and their labels from various perspectives.
> I.e. 'the element dofs of element k' and 'the entity dofs of entity (d,i)'
> are both sets of dofs that can be labeled by multiple numbering schemes.
> I'll make pull requests for eventual naming changes I do.
>
>
>> > 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)
>> >
>>
>> I'm not too keen on the name 'universal dofs'. We want these dofs
>> belong to a (sub)-domain. Maybe 'domain dofs'?
>
>
> Do we? What's the advantage? It seems to me that the machinery needed
> for handling constants varying with the (sub-)domain is overkill when the
> user can just use different globally defined constants in different parts of
> the forms.
>
Once we support Lagrange multiple like terms ('Reals') on subdomains,
we will want to order dofs differently/separately on different
subdomains. Moreover, in parallel we don't want to carry dofs that
aren't active on the process.
Garth
> But I don't mind 'domain dofs'. We can use that name initially without any
> subdomain selection until we see a concrete need to add that.
>
>
>> > 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),
>>
>> This should be 'an arbitrary number of cells/entities' rather than 'all
>> cells'.
>
>
> True if we end up implementing domain dofs associated with subdomains,
> which I think we may avoid but we'll see what we end up with when we get
> there.
> I'll begin with adding domain dofs without a domain association, then we can
> extend it later if needed.
>
>
>> > - 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.
>> >
>>
>> Depends on how one defines 'local dofs'. If local dofs are all dofs in
>> the dofmap on a process, then yes they're local. If local dofs are
>> those that have been numbered by the process, then the ghosts are not
>> local.
>>
>> From a high level, I think it's better to think of dofs maps as
>> overlapping. The question of 'ownership' only comes up when
>> initialising the data structures for some linear algebra backends.
>>
>> For this reason, I have been planning to deprecate
>> GenericDofMao::ownership_range() now that dofmaps use process-wise
>> indices.
>
>
> Ok. From the UFC/FFC point of view it doesn't matter, so I can go ahead
> adding 'domain dofs'
> and see if I can clean up some naming related to 'cell dofs' and 'element
> dofs'.
>
> Martin
>
>
>>
>> Garth
>>
>> > ** 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.
>> >
>> > Martin
>> >
>> > _______________________________________________
>> > fenics mailing list
>> > [email protected]
>> > http://fenicsproject.org/mailman/listinfo/fenics
>> >
>
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
