[dune-fem] periodic conforming FE

[Martin Nolte]

Hi Andreas,

currently, the code resides in my private dune-fem branch. It should not be too 
hard to port the DofMappers and the adapted Lagrange space to dune-fem's master. 
Until today, however, I thought there was no real interest.

Given the others agree, I can put these changes onto my todo list for the 
master. But changing the template argument list of the Lagrange space (even if 
the new argument is defaulted), might have a subtle impact on user code as 
specializations for the Lagrange space might fail to compile.

But the way: What's wrong with using YaspGrid and the "communicate" approach for 
you? It should be far easier to use and code in the master branches undergoes a 
lot more testing than my private stuff.

As for the why I decided against the "communicate" approach: That's a longer 
story. I'll try to keep it as short as possible:

I have been trying to implement the "communicate" approach in the 
ParallelSimplexGrid. This turned out to be especially hard in the serial case, 
because you need ghosts that are copies of elements on the same process. As 
these have the same id, I had a hard time telling them apart. Note that at that 
time I was still sailing extremely near to the official DUNE interface; I did 
not consider an id that differs for copies and simply provide an additional 
mapping to satisfy DUNE's artificial requirements.

At some time I managed to get PSG working. When Alberta started supporting 
periodicity, I also tried to include AlbertaGrid to support periodicity. Again, 
the requirement to make an intrinsically serial grid support copies of the same 
entity would have generated a huge work load and noticeable performance overhead.

Somewhen around that time we also started playing around with GeometryGrid. I 
then realized that I might want to use a 2d grid that is periodic in x, but not 
in y and map it to a quarter of an annulus. But how shall I assign the new 
coordinates to the entire grid: Use ids, of course. But that was impossible, 
because vertices on the periodic boundary get the same id, so they must be 
assigned the same coordinate -- oops.

Thinking the problem through, I also came up with a last point: What if my 
discrete function actually models a vector field (e.g., stokes) on the 
above-mentioned annulus? In this case, the vectors pointing up on one periodic 
boundary need to point (e.g.) right on the other. In continuous finite elements, 
the degrees of freedom would not match directly.

All these problems magically disappeared when switching the point of view to the 
"gluing" approach. I envisioned periodicity as a boundary condition. 
Consequently, it should be the user's decision what should happen at the 
boundary. The price for this kind of flexibility the more difficult 
implementation of boundary conditions.

Today, I see things differently. I think both approaches are good and valid and 
I can provide solutions to nearly all the problems I mentioned above (one 
exception is legacy code like AlbertaGrid). The id problem, for example, can be 
resolved by specifying the periodic "copies" do not have the same id. The issue 
with degrees of freedom for a vector field can be resolved by using the a simple 
DoF transformation (similar to Piola).

In the above discussion I tried to keep out one point: Except for me, no one 
within the DUNE community was really interested in periodicity. Whenever I tried 
to discuss the problems in a larger circle (e.g., FlySpray), I got no answer. In 
the end, I was only interested in getting my code to work.

I hope this sheds some light onto the situation and why things are the way they 
are without too much moaning.

Best,

Martin

PS: ParallelSimplexGrid is still running with my version of dune-grid. I don't 
know how much work a backport to the master will be. I guess, once the 
2.4-release is out and we can remove the compatibility layers, making it work 
with the master should be quite simple. For myself, I removed all compatibility. 
After all, I am my only user.


On 06/05/2015 05:46 PM, Andreas Dedner wrote:
> On 05/06/15 11:55, Martin Nolte wrote:
>> Of course, you can reinterpret the PeriodicDofMapper as a DofMapper enforcing
>> (currently quite simple) constraints. But a generalization to support, for
>> example, the removal of DoFs (like for H^_0) requires the concept of a dof
>> transformation, which is not yet available in dune-fem.
>>
>> I should mention that the identification of DoFs is not as generic as I would
>> like it to be, because this issue is related to the twist discussion.
> Do you think this would be usable for me based on the 1.4 release?
> I think the student will be working with p=2 in 2d at most.
> What I mean is, can I import the classes for the dofmapping from some repo and
> modify the Lagrange space to take an extra template.
>
> Why have you decided that the "communicate" approach is not the right one?
> Best
> Andreas
>
> PS: sorry for mixing question, is your twist free simplex grid still functioning?

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany