Ok - so there is one hiccup. In mesh_communication.C in redistribute()... there is the assumption of only one boundary id per node. It looks like it packs the following into node_bcs_sent: node1 bc1 node2 bc2 etc...
I propose changing that to: node1 numbc1 bc1 bc2 bc3 node2 numbc2 bc2 bc3 etc... Essentially just adding the number of bcs attached to that node to the packing and then listing all of the bcs out that are attached to that node. And then obviously doing the correct thing on the other side to unpack them, Anyone see any holes in this? Derek On Tue, Mar 31, 2009 at 10:13 AM, Derek Gaston <[email protected]> wrote: > On Mar 30, 2009, at 5:14 PM, Roy Stogner wrote: > > >> On Mon, 30 Mar 2009, Derek Gaston wrote: >> >> So... after trying to actually use my little hack to create nodesets >>> from sidesets... I ran into an interesting problem... I really do need >>> multiple boundary ids per node. The reason? Multiple variables. >>> Think about two boundaries that touch... on one boundary I have >>> Dirichlet conditions on "u" on the other I have Dirichlet conditions >>> on "v".... at the nodes that they share I _really_ need to be able to >>> set the conditions for both variables.... it's easy to think of this >>> situation if you think about no penetration BCs.... >>> >> >> I agree. >> >> So I'm thinking... why don't we just make the std::map for >>> _boundary_node_id in BoundaryInfo into a std::multimap... >>> >> >> I also agree here. >> >> just like the _boundary_side_id map for elements? >>> >> >> I sadly disagree completely here: "just like the side ids" would >> imply that the APIs are still constructed without multimap entries in >> mind and that the library functionality for things as basic as >> writing boundary ids to file should be untested at best and probably >> outright broken. :-P Seriously, just look at the comment by and the >> definition of BoundaryInfo::boundary_id(elem,side) - the most basic >> API for accessing the multimap, and it outright assumes that your >> multimap is just a map! >> >> If, on the other hand, you want to make the node ids into a multimap >> that actually *works* (and maybe fix the side id multimap support at >> the same time?) then I'd be entirely in favor! >> > > > Correct me if I'm wrong... but I don't see any mesh formats that actually > write out the nodeset information. The only API type place I can see that > uses the node bc stuff is in mesh_communication... and there they only use > build_node_list... which will still work fine with the multimap. I do see > where some mesh input formats _add_ nodes to boundary_info.... but that > won't be modified by making this change. > > Now... that does bring up the subject of whether or not mesh I/O stuff > _should_ be outputting node boundary info.... but I think that's work for > another day. > > As for the element / side boundary multimap... unfortunately I don't have > time for that right now... but it is good to know that that is the case. > I'll keep it in the back of my mind for when I get some free time. > > I'm going to go ahead and make the node map -> multimap change and see if > it will work. > > Derek >
------------------------------------------------------------------------------
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
