[dune-fem] periodic conforming FE

Martin Nolte nolte at mathematik.uni-freiburg.de
Fri Jun 5 12:55:48 CEST 2015


Hi Andreas,

let me start with your second question. To my knowledge, the grid support for 
periodic discretzistions has never been discussed. Currently, there are 
basically two approaches:

(1) assume that you have a parallel grid covering the entire R^n

This grid is considered to be distributed to infinitely many processors. Of 
course, there are only p processes that actually differ. All other ones are 
"faked" though communication with the correct perioidc copy, which will always 
be a ghost or overlap element. This approach is, for example, implemented in 
YaspGrid. In this case, the domain (R^n) has no boundary and ghost neighbors 
obviously need their own index. The question whether ids should equal or not is 
(to my knowledge) still open. In an ideal world, your FE code should run 
out-of-the-box, because the grid communication already manages the 
identification of vertices.

(2) assume opposite faces of your unit cube are glued together

In this approach, your (portentially serial) grid models only the unit cube and 
all boundaries are marked as such. However, the grid "knows" about the glue and 
boundary intersections will return the glued neighbor. This intersection behaves 
mostly like a non-conforming intersection, i.e., all subentities have different 
indices, ids, etc. As stated above, the grid is not required to be parallel 
(i.e., all parallel methods might be stubs). Therefore, in the serial situation, 
the outside elements of an intersection will not be a ghost but the 
(untransformed) interior element "glued" to the inside element. Obviously, if 
the grid is parallel, the neighboring element might be a ghost or overlap 
element. This approach is, for example, implemented for AlbertaGrid, ALUGrid, 
and SPGrid. For more details on this approach, have a look at the appendix of my 
phd thesis.

Unfortunately, there has never been much interest in the support of periodic 
boundary conditions (neither in the core, nor in dune-fem). For this reason, I 
was always forced to work around some problems. Anyway, here's a brief history 
of my solution:

My first approach was a periodic grid part (basically an index set identifying 
the higher-codim entities with their periodic copies). As a drawback, this never 
worked very well with VTK output, because it uses the vertex index to address 
the actual coordinates in a vector, so I finally dropped this idea.

The next solution I came up with (and which I am still using) is to identify the 
degrees of freedom in the Lagrange space by replacing the DofMapper (extra 
template argument). Actually, this venture is where the IndexSetDofMapper comes 
from. Additionally, there has always been a PersistentIndexDofMapper (which 
basically does the same thing as the adaptive leaf index set, but for degrees of 
freedom). A small variant of the latter one is the PeriodicDofMapper. On 
"compress", it unifies periodic copies of the same DoF.

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.

Sorry, for the lengthy (and maybe a bit moaning) answer. I hope it helps to 
grasp the status quo and the location of the "construction sites".

Best,

Martin



On 06/05/2015 10:38 AM, Andreas Dedner wrote:
> Hi.
> I need a periodic conforming FE discretization. I know that there have been
> different approaches
> and I was wondering if someone has something lying around in some branch.
>
> If not then my idea was to do it along the lines of the Constraints class, i.e.,
> postporcessing the
> matrix and the rhs after normal assembly as we do it for the dirichlet data.
> Basically I wanted to
> identify the parallel nodes, setup a master/slave vector. Then the rows in the
> matrix belonging to slave(s)
> are added to the row of the master and the rows for the slaves is replaced by a
> (0..0 -1 0...0 1 0...0)
> leading to u_s-u_m = 0. This would require some more methods on the linear
> operator class similar to
> clear row.
> If somebody has some better idea I would be happy to hear about it.
>
> Second question: for those developing grids what semantics for periodic
> boundaries did you assume (if any).
> I know that this has never been defined very well in the dune interface. Is it
>       intersection.neighbor()=true and intersection.boundary()=true and
>       intersection.outside return a "ghost"?
> The documentation also states that the index of that ghost is different from the
> index of the periodic inner element (ids are the same. But DG seems to work out
> of the box so I'm assuming in dune-fem its done differently....
>
> Thanks for any pointers, best
> Andreas
>
>
>
> _______________________________________________
> dune-fem mailing list
> dune-fem at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-fem

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




More information about the dune-fem mailing list