Roy Stogner <[email protected]> wrote on 09/29/2010 02:42:58 PM:
> > On Wed, 29 Sep 2010, David Andrs wrote: > > > However, there is something strange on the refined mesh. The element 4 > > (the very bottom left one - child of element 0) has the same info as its > > parent - that is still ok. But, if I look at the elements 5, 6, 7 which > > are the three remaining child elements of element 0, they do have the same > > boundary info like element 0, i.e. local edges 0 and 3 have the same > > boundary ids. I would expect that element 5 would have only boundary info > > associated with local edge 0, element 6 only with edge 3 and element 7 > > would not have this info at all since it is an interior element. In other > > words, the child elements inherit the boundary info from the parent > > element. > > Not just inherits - specifically references. Check boundary_info.C, > line 466. By using the top_parent() boundary info we never even have > to duplicate the ids, which is nice. > > And it works for most apps, since we don't bother to check boundary > ids until after checking that a neighbor is NULL (i.e. that we're > actually on the domain boundary). > I was not sure if this was an expected behavior or it was just me doing something wrong. However, I need that for internal boundaries as you mentioned below. > A workaround for some types of internal boundaries is to use subdomain > ids: i.e. if you're in subdomain 1 and your neighbor is in subdomain 3 > then you apply whatever interface condition is associated with > std::pair<>(1,3). Our boundary ids come as a sideset ids from exodus file. So as long I'm able to iterate over the sideset and figure out the neighboring subdomain id, this would be a way to go. > > If that workaround isn't sufficient for your case then we should talk > about changing the API behavior. If internal boundary ids are all > defined on the coarse mesh, then additional cases to handle that would > be quick and easy. If you need to change boundary ids as you refine > then life gets harder. So far, we do not need to change the boundary ids as we refine the mesh. One more thought: I'm not really familiar with libMesh internals, but as long as the local edge/face ids are preserved (I suspect they are, from what I saw so far), it should be possible to not copy the references for new internal edges that were created by the refinement and copy only the "outer" ones. Or not? Thank you, -- David Andrs > --- > Roy > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
