[Dune] Periodicity for unstructured grids

[Aleksejs Fomins]

Dear Matteo,

Thank you for your answer. While I see the intuitive motivation of having translated periodic ghost elements, I would currently prefer to keep the periodic neighbor there where it is and not translate it. In Floquet's (Bloch's) theory, applicable to i.e. electromagnetics, the field must obtain a phase factor depending on the distance between periodic boundaries, and thus the user code must be aware of periodic neighbors and treat them differently from interior and ghost neighbors. In effect, creating translated elements increases grid complexity and storage, but I do not see yet how it would simplify the user code. When calculating the coupling matrices, integrated over the periodic boundary, the contributions from each neighbor can be evaluated using the same local coordinate, given that the elements are adjusted by the grid to exactly match the orientation.

I have a question: How does one denote a periodic boundary in Dune? As far as I am aware, the partition types are

border,
interior,
front,
overlap and
ghost

Is there some other variable within the grid that is responsible for the periodicity?

Best regards,
Aleksejs


On 12.12.2016 08:42, Matteo Semplice wrote:
> Dear everybody,
>
>     a few years ago I had raised the issue that the behaviour of dune was in fact different from what announced in the documentation. In particular I read the documentation as saying "if you ask for the outer element from an interface on a periodic boundary, you get a fake element with the periodically transformed geometry but the id of the real element". This would allow to make no change at all in the user code for periodic boundaries, since the user would not see at all the boundary. Unfortunately most grid implementations at the time did not comply to this statement and the discussion on the list ended with "we will change the documentation", which was entirely fair since I was not volunteering to do the job! So, on the one hand, this is just to say that it's not that I lost interest, I just stopped asking (since again I do not feel I have the ability to do the job).
>
> On the other hand, at the time I had written a small code that can be compiled with the usual "GRIDTYPE=XX GRIDDIM=NN make" trick and that checks the behaviour of dune on periodic interfaces for that grid implementation. Needless to say that I would be happy to share it, if it can be of interest to anyone working on periodic boundaries.
>
> Best regards,
>     Matteo
>
> On 09/12/16 12:53, Martin Nolte wrote:
>> Hi Aleksejs,
>>
>> there has been quite some discussion on periodic boundary conditions.
>> Currently, there are two approaches:
>>
>> Approach 1:
>>
>> Consider the flat torus T^n = R^n / Z^n. In this case, you can condider your
>> computational domain to be R^n itself and theoretically imagine a grid with
>> infinitely many elements such that for each (geometrical) element E and each i
>> in Z^n, E + i is also an element of the grid. Factoring out Z^n, you end up
>> with a grid for T^n.
>>
>> Now, imagine you also have infinitely many processors and assign to each cube
>> [0,1]^n to one processor. This case can (theoretically) be handled by the
>> parallel interface. As each process only has a shifted copy of the grid, we
>> periodicity allows us to consider only one representative of the parallel
>> processes, i.e., 1 process (which then communicates with itself). I hope it is
>> clear how this can be extended to multiple "real" processors.
>>
>> This approach is implemented in YaspGrid.
>>
>> There is one little tweak to notice: As far as I know, the identified elements
>> are considered copies of each other. This might lead to problems with the
>> coordinate function, which is not periodic at all. I'm not sure whether this
>> question was thoroughly discussed, though.
>>
>>
>> Approach 2:
>>
>> Let us consider the flat torus to be constructed by glueing together opposite
>> sides of the unit cube. In other words, we consider elements on the right
>> boundary to have an intersection with elements on the left boundary (and vice
>> versa). But that's it, the subentities are not identified.
>>
>> In this case, parallelization is also clear. For each intersection, the
>> neighboring element should exist as a ghost.
>>
>>
>> A few years ago, there was quite some discussion on this, but people seem to
>> have lost interest. I'm not sure whether there is a "right and wrong".
>> Personally, I consider both approaches viable, depending on your goal.
>>
>> Best,
>>
>> Martin
>>
>> PS: You can find some more information in the appendix of my phd thesis.
>>
>>
>> On 12/09/2016 11:52 AM, Aleksejs Fomins wrote:
>>> Dear Dune,
>>>
>>> I need to implement periodic boundary conditions into dune-curvilineargrid now.
>>>
>>> Would you be so kind to tell me if the current dune-grid interface envisions periodic boundaries and associated ghost elements, and how.
>>>
>>> The questions of interest are: partiton type, behavior of intersection, behavior of DataHandle
>>>
>>> Best regards,
>>> Aleksejs
>>>
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune