[Dune] Periodicity for unstructured grids

[Matteo Semplice]

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
>>