From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050511 21:23:11

That is true. When the intersection of a parent side and child side is not empty then the two sides are the same number. This assumption is used in the BoundaryInfo class. If you have a child and you want to know if side s has a BC associated with it then you ask the parent if they have a BC for side s, and so on recursively. That way the BoundaryInfo class is not affected by refinement. The only element where this was awkward is the Pyramid. Naturally, you might want the square base to be side 0, but that won't work because the 4 triangular faces need to be sides 0,1,2,3 so this assumption will work for the tetrahedral children. So, the square base is side 4. Ben Original Message From: libmeshdeveladmin@... [mailto:libmeshdeveladmin@...] On Behalf Of Roy Stogner Sent: Wednesday, May 11, 2005 2:54 PM To: libmeshdevel@... Subject: [Libmeshdevel] Refinement assumptions Currently, the projectionbased constraints calculation makes the following assumption: when the side of a child element and the face of its parent overlap, the side numbers (i.e. the indices to pass to build_side) of the overlapping sides are equal. Is this true for every element? I've only tested a couple personally. With every element except Tet10, a child whose sides overlap its parent's sides will be an affine transformation of its parent, and so giving it the same (local) node numbering seems natural. I'd rather not pore over a dozen _embedding_matrix arrays to verify that, though, if someone knows the answer offhand. I think I've asked this before, but if so I can't find it in the libmeshdevel archives. In any case I'm about to repeat this assumption in some more code, so reassurance would be appreciated.  Roy  This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Libmeshdevel mailing list Libmeshdevel@... https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Benjamin S. Kirk <benkirk@cf...>  20050513 03:14:14

Maybe the straightforward approach is to use the neighbor information to figure that out. Consider a child element. it has n face neighbors, some of which are siblings, others are from an adjacent element refinement hierarchy. You can loop over all the sides of a child, those neighbors with a different parent are on sides that intersect with parent element sides. All the "internal" sides (sides of the child that do not intersect with a parent's side) will be shared with siblings that have the same parent. So, if ((child>neighbor(s) == NULL) \\ on boundary  (child>neighbor(s)>parent() != child>parent())) then the intersection of parent>side(s) and child>side(s) is not empty As for the node assumption, I'm not positive... You can verify it by checking for the identity rows in the embedding matrix. It suffices to check for the simplest element types, i.e. HEX8 and then it will hold true for all the HEXes. Ben Roy Stogner wrote: > On Wed, 11 May 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > >> That is true. When the intersection of a parent side and child side >> is not >> empty then the two sides are the same number. > > > Okay, then, my only remaining question is "when is the intersection of > a parent side and child side not empty?" > > Yeah, I wish I were kidding. But I'd like to be able to compute this > information (which I'll be adding as Elem::is_child_on_edge() and > Elem::is_child_on_side() ) in advance; the easy implementation of > building both sides and checking for common nodes would add yet more > time to a coarsening projection that already looks unpleasantly slow. > > Would I guess right in assuming that child i shares local vertex > number i with its parent? If that's true, it's enough information for > me to implement all the Tri/Quad/Hex is_child_on_* functions easily, > and I can puzzle through the remaining Tet and Pyramid children from > the embedding matrices. > > Thanks, >  > Roy > > >  > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Roy Stogner <roystgnr@ic...>  20050512 22:03:38

On Wed, 11 May 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > That is true. When the intersection of a parent side and child side is not > empty then the two sides are the same number. Okay, then, my only remaining question is "when is the intersection of a parent side and child side not empty?" Yeah, I wish I were kidding. But I'd like to be able to compute this information (which I'll be adding as Elem::is_child_on_edge() and Elem::is_child_on_side() ) in advance; the easy implementation of building both sides and checking for common nodes would add yet more time to a coarsening projection that already looks unpleasantly slow. Would I guess right in assuming that child i shares local vertex number i with its parent? If that's true, it's enough information for me to implement all the Tri/Quad/Hex is_child_on_* functions easily, and I can puzzle through the remaining Tet and Pyramid children from the embedding matrices. Thanks,  Roy 
From: Benjamin S. Kirk <benkirk@cf...>  20050513 03:05:41

Maybe the straightforward approach is to use the neighbor information to figure that out. Consider a child element. it has n face neighbors, some of which are siblings, others are from an adjacent element refinement hierarchy. You can loop over all the sides of a child, those neighbors with a different parent are on sides that intersect with parent element sides. All the "internal" sides (sides of the child that do not intersect with a parent's side) will be shared with siblings that have the same parent. So, if ((child>neighbor(s) == NULL) \\ on boundary  (child>neighbor(s)>parent() != child>parent())) then the intersection of parent>side(s) and child>side(s) is not empty As for the node assumption, I'm not positive... You can verify it by checking for the identity rows in the embedding matrix. It suffices to check for the simplest element types, i.e. HEX8 and then it will hold true for all the HEXes. Ben Roy Stogner wrote: > On Wed, 11 May 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > >> That is true. When the intersection of a parent side and child side >> is not >> empty then the two sides are the same number. > > > Okay, then, my only remaining question is "when is the intersection of > a parent side and child side not empty?" > > Yeah, I wish I were kidding. But I'd like to be able to compute this > information (which I'll be adding as Elem::is_child_on_edge() and > Elem::is_child_on_side() ) in advance; the easy implementation of > building both sides and checking for common nodes would add yet more > time to a coarsening projection that already looks unpleasantly slow. > > Would I guess right in assuming that child i shares local vertex > number i with its parent? If that's true, it's enough information for > me to implement all the Tri/Quad/Hex is_child_on_* functions easily, > and I can puzzle through the remaining Tet and Pyramid children from > the embedding matrices. > > Thanks, >  > Roy > > >  > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Roy Stogner <roystgnr@ic...>  20050513 03:26:53

On Thu, 12 May 2005, Benjamin S. Kirk wrote: > if ((child>neighbor(s) == NULL) \\ on boundary >  (child>neighbor(s)>parent() != child>parent())) > then the intersection of parent>side(s) and child>side(s) > is not empty That's too fragile at the moment (Mesh::find_neighbors currently wipes everyone's neighbors and doesn't reassign neighbors of subactive elements) but it's clearly the best way to go once that's fixed. Thanks!  Roy 