[petsc-dev] Periodic meshes with <3 elements per edge?

[Jed Brown]

I think this thread got dropped when I was on travel (two months ago and
I'm just now getting back to it, eek!).  Matt, could you please comment
on this model?

Jed Brown via petsc-dev <petsc-dev at mcs.anl.gov> writes:

> Matthew Knepley <knepley at gmail.com> writes:
>
>>>> >> The local points could be distinct for
>>>> >> both fields and coordinates, with the global SF de-duplicating the
>>>> >> periodic points for fields, versus leaving them distinct for
>>>> >> coordinates.
>>>> >
>>>> >
>>>> > Oh, no I would never do that.
>>>>
>>>> Can you help me understand why that model is bad?
>>>>
>>>
>>> I'm also interested in the answer to this question, because I am
>>> considering something similar for DMStag; if DM has a periodic BC, the
>>> corresponding coordinate DM has a "none"  BC, so the boundary points are
>>> duplicated - this would hopefully make it much easier to locate particles
>>> in elements.
>>>
>>
>> If you start asking topological questions of the mesh, it looked
>> complicated to get them all right. For example, if you start expanding
>> the overlap over the periodic boundary. 
>
> How is this different from what we have now?  You have to go through
> global points anyway to connect between processors, so why would it
> matter if the point and its periodic alias may appear separately in a
> local space?
>
>> Fundamentally, periodicity is a topological notion. It is not defined
>> by the coordinate chart.
>
> The global SF would be the same as you have now.  The local SF would
> distinguish the alias only so those points would be valid in the
> coordinate chart.  So the periodic mesh
>
>   A -- B -- C -- D -- a
>
> on two processes would be represented via the cones
>
>   {AB, BC}  {CD, Da}
>
> with l2g
>
>   {0,1,2} {2,3,0} for fields
>   {0,1,2} {2,3,4} for coordinates
>
>
> Why doesn't this work, or where is the greater complexity of this model
> versus the present scheme of localizing coordinates?