Introduce PeriodicBasis

PeriodicBasis is a meta basis---a basis that is parametrized with another basis. In a PeriodicBasis, global degrees of freedom of the host basis can be grouped into equivalence classes, which are then treated as single global degrees of freedom by the PeriodicBasis. This allows, in particular, to implement periodic boundary conditions for discretizations without intersection integrals.

In an email dated 2020-06-03, @christi wrote:

ich bin mir nicht sicher, ob das wirklich der Ansatz ist, den wir wollen.

Für mich ist das ganz dicht an dem, was wir bei hängenden Knoten mit Constraints machen müssen. Ich denke es ist sinnvoller das "außen" drum herum zu machen. Aber ich lasse mich da auch "überzeugen"

To which @carsten.graeser replied (2020-06-04):

ich bin mir nicht sicher, ob das wirklich der Ansatz ist, den wir wollen.

das habe ich auch erst gedacht, aber ...

Für mich ist das ganz dicht an dem, was wir bei hängenden Knoten mit Constraints machen müssen. Ich denke es ist sinnvoller das "außen" drum herum zu machen. Aber ich lasse mich da auch "überzeugen" Natürlich kann man das auch mit Constraints außenherum machen, wie bei konformen Base. Aber das ist nicht so trivial und man muß das komplette Interface von allem was einen Basis benutzt aufblähen, damit das sauber geht. Das ist noch einige Arbeit.

Im Gegensatz dazu geht dieser Ansatz mit dem bestehenden Interface. D.h. das ändert nichts am Basis-Interface sondern ist nur eine weitere Basis-Implementierung. Insofern finde ich das relativ elegant. Außerdem spart man sich die Koffizienten zu speichern und auszuwerten, die man in einer Basis mit Constraints hat. Deshalb bin ich dafür das in dune-functions zu packen.

Zur konkreten Implementierung habe ich noch einige Hinweise:

• Es scheint zunächst so, als könnte man damit nur flache Bäume darstellen. Das ist aber nicht so: Man kann einfach eine Periodic-Basis in verschiedenen Blatt-Knoten habe. Damit ist auch Power(...) kein Problem.
• Was damit nicht geht ist Periodizität über verschiedene Blätter hinweg. Aber da halte ich würklich für eher esoterisch. Wenn man das will, muß man es halt manuell bauen.
• Das sollte ohne Probleme als Meta-PreBasis gehen. Die Einschränkung wäre zunächst das die gewrappten Indizes skalar sind. Aber da könnte man Speziallfäller (DG mit Element-Blocking) auch später nachimplementieren, wenn man will.
• Man kann sich die Implementierung des Node sparen und direkt den gewrappten rausreichen, aber es geht noch einfacher...
• Das ist nur ein Spezialfall einer Index-Transformation. D.h. man kann einfach von TransformedIndexPreBasis ableiten und muß nur noch die konkrete Re-Indizierung selber implementieren.

Gruß, Carsten

PS: Wenn ich mir das ansehe, habe ich den Eindruck als ob man das eventuell auch als Muster für eine Implementierung von Contrained-Bases nutzen könnte. Das ließe sich auch elegant intrusiv in den Blättern lösen. Natürlich müßte man ein Spezielles LFE mit skalierten Basisfunktionen herausreichen. Aber dann sollte fast alles gehen. Nur die Interpolation bereitet dann Probleme, weil wir dann einen DOF nicht mehr in jedem Element aus dem Support interpolieren können. Aber das könnte mit einer sehr minimalen Interface-Erweiterung gehen.

In principle I like the idea to have a periodic basis wrapper. Currently, everyone has to implement this in some way herself with in some cases a similar concept. So, if this could be a general part of the interface, it would unify some code.

Another approach I have followed some time ago, but couldn't finish until now, is to add a periodic layer over the grid(view). There, you have to associate grid entities by some equivalence class, not the DOFs itself. Then, in this layer the number of unique entities can differ from the host grid and also the indices of entities might differ. Thus, you could directly put a dune-functions basis on top and get periodic DOFs "for free". This requires that the grid has already a periodic structure, but a similar requirement you probably have with the periodic dune-function wrapper as well.

I had the same idea (and a few others), but I cannot make up my mind which one is best. Most approaches that I can think of have advantages and disadvantages, and there doesn't appear to be a clear winner.

What about parallel periodicity, using a distributed grid where associated DOFs might be on different processors. This is probably in all approaches not so easy.

That's why the YaspGrid approach to periodicity was invented. There, a periodic boundary needs explicit communication just like subdomain boundaries do.

I like the idea of associating the DOFs manually, by calling unifyIndexPair, so the actual association of boundaries is extracted from the periodic basis. It just gets a bit more complicated when associating higher-order DOFs, since a "twist" in the edge/face orientation is needed to find the right index when an association of entities is just available, or the DOF must be identified by global coordinates or something similar.

added 2 commits

• 2914fad5 - Introduce PeriodicBasis
• 6e16b66a - Add unit test for PeriodicBasis

Compare with previous version

I think that the proposed approach is more general than what I consider representable with a periodic grid view. It is purely algebraic and allows to 'glue' together very different degrees of freedom. It also follows the dune-functions idea that indices can be anything and are not necessarily related to grid entities.

Unless you have directional DOFs (e.g. for Hermite and edge elements) the proposed approach should be capable to cover any type of geometric periodicity. From my perspective a grid view based approach that simplifies the geometric association of DOFs could be implemented on top of this.

I'd not consider parallel grids for now since they have not bin addressed inside of dune-functions anyway.

added 1 commit

• 3969359c - WIP: Unit test for power<periodic>

Compare with previous version

added 11 commits

• 3969359c...4baee24b - 6 commits from branch master
• 4e4952e9 - Introduce PeriodicBasis
• 01f0948a - Add unit test for PeriodicBasis
• dae0d339 - WIP: Unit test for power<periodic>
• 32310c85 - Implement a periodic pre basis using index transformation
• e02696e4 - Test new periodic basis interface

Compare with previous version

added 1 commit

• 23731764 - [test] Test all possible constructions of a PeriodicPreBasisFactory

Compare with previous version

After discussion with @oliver.sander I just force pushed an updated version:

• Rebase on master.
• Reimplement the PeriodicPreBasis using TransformedIndexPreBasis. We just need to pass a special index transformation.
• Adapt test and activate basis check for power(periodic(...)).

Now you can create a PeriodicPreBasisFactory using periodic(foo, periodicIndices)) where foo is either a PreBasisFactory, a PreBasis, or a GlobalBasis and periodicIndices stores the identified indices. The PeriodicPreBasisFactory can be passed to makeBasis and nested using power()and composite() as usual. Currently passing a PreBasis or GlobalBasis for foo will only work, if the MultiIndex type of the wrapped and the wrapping basis coincide.

Thanks, @carsten.graeser . I tried the new implementation in my code now, and as far as I can tell right now it works nicely.

assigned to @oliver.sander

@oliver.sander reassigning to you. Feel free to merge or improve this.

added 16 commits

• 23731764...7b22177a - 10 commits from branch master
• 34f1a42e - Introduce PeriodicBasis
• 029b71db - Add unit test for PeriodicBasis
• ed4c16d9 - WIP: Unit test for power<periodic>
• c80052f6 - Implement a periodic pre basis using index transformation
• 8e89bc3b - Test new periodic basis interface
• 0b24f9b5 - [test] Test all possible constructions of a PeriodicPreBasisFactory

Compare with previous version

unmarked as a Work In Progress

changed the description

I recently came across a potential shortcoming of this approach while trying to implement a Nédélec space with periodic boundaries. There, unifying degrees of freedom is not enough: An additional sign change may be necessary...