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