[MOAB-dev] Edges at the ends of a periodic mesh?

Xiabing Xu xbxu at mcs.anl.gov
Fri May 25 14:43:34 CDT 2012


On May 23, 2012, at 11:20 PM, Timothy J. Tautges wrote:

> 
> 
> ----- Original Message -----
>> From: "Robert Jacob" <jacob at mcs.anl.gov>
>> To: "Timothy J. Tautges" <tautges at mcs.anl.gov>
>> Cc: "Iulian Grindeanu" <iulian at mcs.anl.gov>, moab-dev at mcs.anl.gov
>> Sent: Wednesday, May 23, 2012 11:17:06 PM
>> Subject: Re: [MOAB-dev] Edges at the ends of a periodic mesh?
>> This was motivated by a more practical question. If there are N cells
>> in the j-direction, there will be N+1 edges but the last is the same
>> as
>> the first. So in the call to box create, do we specify N vertices in
>> the j-direction or N+1? I'm still not sure.
>> 
> 
> In parallel, N+1, with is_periodic false.  In serial, N, with is_periodic true.
> 
Do you assume the partition is over j direction? What if the partition is over other directions, which ends up with the mesh on each process is really a periodic mesh?

Xiabing

> - tim
> 
>> Rob
>> 
>> 
>> On 5/23/12 10:26 PM, Timothy J. Tautges wrote:
>>> Yes. But, in parallel, each piece of mesh looks like a serial mesh,
>>> so locally it won't appear periodic (the right hand edge will be
>>> distinct from the left hand edge). Logically across processors,
>>> though, the right edge on the rightmost processor will be the same
>>> as the left edge on the leftmost processor. If you write the mesh to
>>> a single file, there will be a common edge between the rightmost and
>>> leftmost quad.
>>> 
>>> - tim
>>> 
>>> ----- Original Message -----
>>> From: "Robert Jacob"<jacob at mcs.anl.gov>
>>> To: "Timothy J. Tautges"<tautges at mcs.anl.gov>
>>> Cc: "Iulian Grindeanu"<iulian at mcs.anl.gov>, moab-dev at mcs.anl.gov
>>> Sent: Wednesday, May 23, 2012 9:13:20 PM
>>> Subject: Re: [MOAB-dev] Edges at the ends of a periodic mesh?
>>> 
>>> 
>>> 
>>> On 5/23/12 9:01 PM, Timothy J. Tautges wrote:
>>>> Be careful about the parallel case though, where on each proc
>>>> sharing the edge the edge is represented.
>>> 
>>> So in the parallel case the edge WOULD be represented on both sides
>>> if
>>> there are multiple processors in the j direction?
>>> 
>>> Rob
>>> 
>>>> 
>>>> Also, if you're just trying to create all the edges in one big
>>>> batch, just put all the quads in a range, then call
>>>> get_adjacencies, with the last argument Interface::UNION, and that
>>>> should create/return all of them.
>>>> 
>>>> - tim
>>>> 
>>>> ----- Original Message -----
>>>> From: "Iulian Grindeanu"<iulian at mcs.anl.gov>
>>>> To: "Robert Jacob"<jacob at mcs.anl.gov>
>>>> Cc: moab-dev at mcs.anl.gov
>>>> Sent: Wednesday, May 23, 2012 12:34:12 PM
>>>> Subject: Re: [MOAB-dev] Edges at the ends of a periodic mesh?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>> 
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> If I have a 2D rectangular mesh which is periodic in one direction,
>>>> lets
>>>> say the j direction, then the leftmost and rightmost edge of the
>>>> mesh
>>>> are really the same edge. Do they both need to be declared in MOAB?
>>>> Or
>>>> does the periodic property mean you only need to describe one of
>>>> the
>>>> edges and the other end will know its adjacent to it?
>>>> 
>>>> Thanks,
>>>> Rob
>>>> Hi,
>>>> I assume that you use ScdInterface;
>>>> If the box is periodic in j direction, the nodes in that direction
>>>> will be "periodic".
>>>> Nodes are not duplicated, the edges that you get on the leftmost
>>>> and rightmost sides are really pointing to the same nodes, they
>>>> will not be duplicated, either.
>>>> 
>>>> How do you get edges after you create quads?
>>>> You can use "get_adjacency" methods, with "create_if_missing" flag
>>>> true. Only one edge would be created.
>>>> The problem is that the order in which these are created is not
>>>> very "structured"
>>>> Or do you create them with new scd boxes, of dimension 1, in a loop
>>>> over i (and then j?)? In that case, you have complete control over
>>>> "order" they are created in.
>>>> I hope this helps.
>>>> Iulian
>>>> 
>>>> 
>>>> Iulian
>>>> 
>>> 



More information about the moab-dev mailing list