> We've currently got side boundary ids stored in a: > > std::multimap<const Elem*, > std::pair<unsigned short int, short int> > > _boundary_side_id; > > Wouldn't it make more sense to use: > > std::map<std::pair<const Elem*, unsigned short int>, short int>? > > The side number (the unsigned short int) is an input to the map, not > an output. And, more important to me, it would be nice to be able to > set the same side id twice and have the previous setting overwritten > (as a set does), not just appended to (as a multimap does). I > triggered a bug this way, when different interpretations of the number > of boundary ids turned out to be inconsistent.
That actually was the original intent - to allow multiple BC ids to be assigned to the same face. You could then apply 'no-slip' and 'isothermal' separately, or no-slip could be the combination of u-symmetry,v-symmetry,w-symmetry, resulting in (u,v,w)=0. This makes sense in a primitive variable formulation, mind you, where the velocity and temperature can be specified independently. In my conserved variable code (the source of the error?) the velocity and temperature are linked, so it is not so useful here... I'm thinking the bug is in the app code, then? -Ben ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
