Lawrence, I wrote the periodic GMSH reader and I can answer for it.
With DMPlex, when we have periodicity, we currently have two ways of encoding it 1) through the maxCell concept (or, as Lisandro's like to call it, the "maxCell crap") 2) through the coordinatesSection Since periodicity with general meshed cannot be encoded with 1), I populate the cell part of the coordinates section with the "localized coordinates" (only for periodic cells), and leave all the other dofs associated with the vertices. I believe this kind of localization is also what you get with the maxCell crap (check it out with the BoxMesh): even in this case in the coordinate section you have cell dofs only for cells touching the periodic boundary, and all the vertices have their own coordinates. Look eg in DMPlexComputeLineGeometry_Internal. What you know for sure is that the first 6 entries of the closure are the ones you should look for (not the size of the closure) 2018-07-12 13:18 GMT+03:00 Lawrence Mitchell < lawrence.mitch...@imperial.ac.uk>: > Dear petsc-dev, > > I am attempting to understand how Plex reads GMSH files with > periodicity. In particular, what happens to the coordinate localisation. > > Here's what I expect: > > When reading a periodic mesh, the coordinate section will not only > associate dofs with mesh vertices, but instead where the "periodic > boundary" is (at least), the vertices have no dofs associated with > them, and instead the cell has the coordinate dofs for that cell. > > Hence, for a triangular mesh, I expect that for every cell, if I call: > > DMPlexVecGetClosure(dm, coordSection, coords, cell, ...); > > That I will always get back an array with 6 entries. > > However, this is not the case. For those cells that have been > identified as periodic, the vertices still have dofs associated with > them, and so I get back 12 entries when calling VecGetClosure, with > each coordinate repeated twice. > > Am I misunderstanding what's going on? > > Cheers, > > Lawrence > -- Stefano
