RestrictedDualSet: inherit entity permutations

[pbrubeck]

Before this PR, RestrictedElement reported no entity permutations, and consumers that orient dofs entity by entity cannot lay out a restricted space consistently with the space it restricts.

By inheriting permuations, an entity whose dofs are all kept by the restriction will keep their relative order, so it would permute under orientation exactly as in the unrestricted case, and an entity whose dofs are all dropped permutes trivially.

An entity that keeps only some of its dofs (a very niche case) has no permutation to inherit, since the ones it drops may be where the parent permutation sends the ones it keeps, so no permutations are reported at all in that case.

[connorjward]

Before this PR, RestrictedElement reported no entity permutations, and consumers that orient dofs entity by entity cannot lay out a restricted space consistently with the space it restricts.

Why is this useful?

since the ones it drops may be where the parent permutation sends the ones it keeps

I don't understand what this means.

[pbrubeck]

Why is this useful?

Consistency in the entity permutations ensures a consistent entity numbering between a FunctionSpace(RestrictedElement) and its unrestricted parent, so that we can use SF/Section to assign across restrictions firedrakeproject/firedrake#5287

since the ones it drops may be where the parent permutation sends the ones it keeps

I don't understand what this means.

RestrictedElement is generic, it can keep any subset of the DOFs on each entity. The most common restrictions are topological, so all DOFs on one entity are either kept or dropped, and propagating the entity permutations is allowed when all DOFs are kept. If only some DOFs are kept, we cannot keep the permutations because then the parent permutation might send parent DOFs to where the child has dropped them.

[connorjward]

Consistency in the entity permutations ensures a consistent entity numbering between a FunctionSpace(RestrictedElement) and its unrestricted parent, so that we can use SF/Section to assign across restrictions firedrakeproject/firedrake#5287

I just want to make sure that this is unrelated to entity_dofs. Data in the global vector is stored by topological entity so is unrelated to some of the FIAT numbering.

RestrictedElement is generic, it can keep any subset of the DOFs on each entity. The most common restrictions are topological, so all DOFs on one entity are either kept or dropped, and propagating the entity permutations is allowed when all DOFs are kept. If only some DOFs are kept, we cannot keep the permutations because then the parent permutation might send parent DOFs to where the child has dropped them.

I guess I have no idea why the entity permutations affect the global data layout. In principle we should be able to support assigning to arbitrary restricted elements using your new approach.

[pbrubeck]

I guess I have no idea why the entity permutations affect the global data layout. In principle we should be able to support assigning to arbitrary restricted elements using your new approach.

The entity permutations were introduced to ensure a consistent DOFs numbering when redistributing a FunctionSpace (via Checkpointing). We only enable them for CG and DG spaces on simplices.

Sure, the SF/Section approach can be made as general as one like, but I'm afraid that mismatching entity-permutations might cost you extra book-keeping that can otherwise be resolved with something so simple as having children elements that obey their parents. I think we can always come back to get the niche case of partrial restrictions on an entity.

Either way, this PR is good on its own.

[connorjward]

I guess I have no idea why the entity permutations affect the global data layout. In principle we should be able to support assigning to arbitrary restricted elements using your new approach.

The entity permutations were introduced to ensure a consistent DOFs numbering when redistributing a FunctionSpace (via Checkpointing). We only enable them for CG and DG spaces on simplices.

Sure, the SF/Section approach can be made as general as one like, but I'm afraid that mismatching entity-permutations might cost you extra book-keeping that can otherwise be resolved with something so simple as having children elements that obey their parents. I think we can always come back to get the niche case of partrial restrictions on an entity.

I'm afraid I still don't see why this PR helps with anything. I have just grepped for entity_permutations in Firedrake and it is exclusively used to build node lists, to reorder DoFs relative to a particular cell or facet. We don't need those for assign because we don't do any packing there.

[pbrubeck]

I'm afraid I still don't see why this PR helps with anything. I have just grepped for entity_permutations in Firedrake and it is exclusively used to build node lists, to reorder DoFs relative to a particular cell or facet. We don't need those for assign because we don't do any packing there.

It does no harm having consistent numbering in the node lists between the RestrictedElement and its parent space. Why should we have them ordered inconsistently if we know how to do it consistently?

Mathematically in FIAT, the restriction operation should propagate every piece of information of the element. Suppose you have a FunctionSpace with no interior DOFs and you restrict it to the facets, the restriction should be a noop. Without this PR that restriction silently gives you a different space.

[connorjward]

I'm afraid I still don't see why this PR helps with anything. I have just grepped for entity_permutations in Firedrake and it is exclusively used to build node lists, to reorder DoFs relative to a particular cell or facet. We don't need those for assign because we don't do any packing there.

It does no harm having consistent numbering in the node lists between the RestrictedElement and its parent space. Why should we have them ordered inconsistently if we know how to do it consistently?

Mathematically in FIAT, the restriction operation should propagate every piece of information of the element. Suppose you have a FunctionSpace with no interior DOFs and you restrict it to the facets, the restriction should be a noop. Without this PR that restriction silently gives you a different space.

This makes perfect sense. I am happy with that argument. I just get concerned when reasons are given that don't make sense.