[MOAB-dev] periodic boundaries

Wed Mar 2 13:37:04 CST 2016

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