[MOAB-dev] periodic boundaries

Wed Mar 2 18:25:38 CST 2016

> For the setup: I am finally aiming at Tets, but triangles are good for testing.

Understood.

> I also found some documentation on structured meshes using hexes  in MOAB (incl. periodic boundaries), could this be extended to triangles and tets (keeping the structure alive)?

Yes that's for a pure structured mesh (ScdInterface) which doesn't
store any connectivity or adjacency information explicitly. You can
use it for stencil computations and apply periodic B.C but it is not
straightforward to extend.

Are you proposing to use a structured grid with triangles and tets here ?

> I am using periodic boundaries mainly for convergence benchmarks: Serial is most important, I wouldn’t say no to a MPI-version though.

As I said, the unstructured mesh doesn't care what you impose as B.C.
You can define sidesets as you need and create sets internally in MOAB
to store the faces on the periodic boundary. Once you have that, you
can internally have a map for adjacency or face-neighbors.

Supporting periodicity also means that we need to do a validation when
we load a mesh. If the topology doesn't match, the whole setup will
fail. Of course the user needs to guarantee this if you want sensible
behavior.

> I need the face-neighbors of my elements: Going through surfaces is therefore the most natural choice. Could also go through vertices and find elements appearing twice (triangles) or three times (tets). Whatever is simple.

I would go through surfaces. For FV/DG, that's natural.

> Tags are a good idea for a workaround: I’ll tell gmsh to forward the periodic boundaries as a tag and then match via the tangential dimensions for a start.

Yes. This is the simplest way to do it.

I'll have to discuss with the team to see if we can support this
natively in parallel. Go ahead with the Tag-based route and let me
know if that suffices for your use-cases. I'll keep you updated as we
continue our discussions.

VIjay

On Wed, Mar 2, 2016 at 1:37 PM, Alexander Nikolas Breuer
<anbreuer at ucsd.edu> wrote:
>> Alex, I don't think we have the necessary semantics to express
>> periodic boundaries natively on an unstructured mesh in MOAB. Partly
>> because, no one asked for it.
>
> Ok, this explains why I couldn’t find any docs on periodic boundaries ;)
>
> For the setup: I am finally aiming at Tets, but triangles are good for testing. It is FV/DG -> Information is shared between face-neighbors (tets) or edge-neighbors (triangles), no dependencies on the vertices. The periodic boundaries are for testing and convergence benchmarks.
>
> I also found some documentation on structured meshes using hexes  in MOAB (incl. periodic boundaries), could this be extended to triangles and tets (keeping the structure alive)? One would “just” have to split the hexes. This way I could use structured meshes with triangles and tets for MPI, however handle them unstructured in my simulations internally. For the serial runs I would go for workaround to get true unstructured meshes in.
>
>> 1) Serial or parallel runs ?
>> a) Serial is relatively much simpler and you can get away with MOAB
>> implementation as it stands.
>> b) Parallel complicates this since the elements on either side of a
>> periodic boundary will be on different partitions and we need to
>> modify shared entity resolution to let it know which process to send
>> messages.
>
> I am using periodic boundaries mainly for convergence benchmarks: Serial is most important, I wouldn’t say no to a MPI-version though.
>
>> 2) Boundary description: nodes vs surfaces (edges)
>> a) In serial, it could be as simple as matching nodes with the same
>> tag value or say Y-coordinate during your setup phase and using that
>> information later during computation
>> b) In parallel, again, you need to rely on resolve_shared_ents to work
>> correctly so that things work out of the box.
>
> I need the face-neighbors of my elements: Going through surfaces is therefore the most natural choice. Could also go through vertices and find elements appearing twice (triangles) or three times (tets). Whatever is simple.
> Tags are a good idea for a workaround: I’ll tell gmsh to forward the periodic boundaries as a tag and then match via the tangential dimensions for a start.
>
>> 3) Do you need adjacency queries ?
>
> During runtime of my simulation? No, after the setup through MOAB all the information goes through an interface into internal structures (pointers, offsets, etc.).
>
>> 4) In parallel, do you expect ghost layers on the periodic boundary ?
>
> Yes, this is the smarter choice. Otherwise I would have to convince the partitioner not to cut along the boundaries.
>
> ***
>
> Something unrelated: Are there thread safe parts in MOAB? E.g. could I use OMP to iterate over my entities and then ask the core for information on those (read only)?
>
> Alex
>
> --
> Alexander Breuer
> University of California, San Diego
> San Diego Supercomputer Center
> 9500 Gilman Drive MC 0505
> La Jolla, California 92093-0505, USA
> http://hpgeoc.sdsc.edu
> +1 (858) 822-5692
>
>
>
>> On Mar 2, 2016, at 9:55 AM, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>
>> Alex, I don't think we have the necessary semantics to express
>> periodic boundaries natively on an unstructured mesh in MOAB. Partly
>> because, no one asked for it.
>>
>> So couple of questions for you.
>>
>> 1) Serial or parallel runs ?
>> a) Serial is relatively much simpler and you can get away with MOAB
>> implementation as it stands.
>> b) Parallel complicates this since the elements on either side of a
>> periodic boundary will be on different partitions and we need to
>> modify shared entity resolution to let it know which process to send
>> messages.
>>
>> 2) Boundary description: nodes vs surfaces (edges)
>> a) In serial, it could be as simple as matching nodes with the same
>> tag value or say Y-coordinate during your setup phase and using that
>> information later during computation
>> b) In parallel, again, you need to rely on resolve_shared_ents to work
>> correctly so that things work out of the box.
>>
>> 3) Do you need adjacency queries ?
>>
>> 4) In parallel, do you expect ghost layers on the periodic boundary ?
>>
>> Depending on what your use case is, this could be done in a variety of
>> ways. Let us know.
>>
>> Vijay
>>
>> On Wed, Mar 2, 2016 at 11:29 AM, Alexander Nikolas Breuer
>> <anbreuer at ucsd.edu> wrote:
>>> Writing about nodes:
>>>
>>> I am searching the neighbors by going from triangles over edges to
>>> neighboring triangles again. Let me know if it's worth trying to go through
>>> the vertices for the boundary.
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 2, 2016, at 9:20 AM, Alexander Nikolas Breuer <anbreuer at ucsd.edu>
>>> wrote:
>>>
>>> Uh, ok. Here's a link:
>>> https://www.dropbox.com/s/f41mmkl47zxrm0a/gmsh.msh?dl=0
>>>
>>> The bnd condition is described in terms of nodes:
>>>
>>> $Periodic
>>> 3
>>> 0 2 1
>>> 1
>>> 2 1
>>> 0 3 4
>>> 1
>>> 3 4
>>> 1 2 4
>>> 9
>>> 14 40
>>> 15 39
>>> 16 38
>>> 17 37
>>> 18 36
>>> 19 35
>>> 20 34
>>> 21 33
>>> 22 32
>>> $EndPeriodic
>>>
>>> Alex
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 2, 2016, at 6:19 AM, Grindeanu, Iulian R. <iulian at mcs.anl.gov> wrote:
>>>
>>> attachment was scrubbed, can you send it again ? maybe as a zip file?
>>> somehow,  it does not like msh suffix
>>> Thanks,
>>> Iulian
>>> ________________________________
>>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf
>>> of Alexander Nikolas Breuer [anbreuer at ucsd.edu]
>>> Sent: Tuesday, March 01, 2016 11:20 PM
>>> To: moab-dev at mcs.anl.gov
>>> Subject: [MOAB-dev] periodic boundaries
>>>
>>> Dear MOAB-team,
>>>
>>> I am trying to read a triangular mesh with periodic boundaries created by
>>> gmsh into MOAB (attached). However I don’t see this when going through
>>> MOAB’s adjacencies. Is there a way to make the mesh reader aware of periodic
>>> boundaries?
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>>
>>>
>>> --
>>> Alexander Breuer
>>> University of California, San Diego
>>> San Diego Supercomputer Center
>>> 9500 Gilman Drive MC 0505
>>> La Jolla, California 92093-0505, USA
>>> http://hpgeoc.sdsc.edu
>>> +1 (858) 822-5692
>>>
>>>
>>>
>