On Wed, 10 Dec 2008, Benjamin Kirk wrote: > 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.
Huh, interesting. That's obviously a sensible idea, but I'd envisioned doing things like that by treating the boundary ids like bitfields, like we'd do with subdomain ids. (or can we overlap subdomains too??) We'd still need to make some major changes to make that work, though: _boundary_node_id should also be a multimap, but more importantly, we'd need some way to actually query multiple bcids! The boundary_id() methods only return one id (and the comments say only one id per side is allowed) Even after we come up with a new API, there's probably other places in mesh/*.C where the "one id per side" assumption is being made. It was in xdr_io.C that I hit that bug, for instance: XdrIO::write_serialized_bcs() gets called with n_bcs==n_boundary_conds(), the total number of boundary conditions set. But it only writes out one id per side (all it can get from BoundaryInfo::boundary_id()), and it asserts that the total number of ids it encounters this way must be equal to the n_bcs from before. --- Roy ------------------------------------------------------------------------------ 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
