[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