On Wed, 1 Dec 2010, Boyce Griffith wrote: > I noticed that adding multiple boundary IDs to the boundary_info object > caused an assertion to fail in xdr_io::write_serialized_bcs() at line > 740 of xdr_io.C, which asserts that n_bcs == n_bcs_out. > > Looking at the code that packs up the IDs, it appears that only the > first boundary ID associated with each side was being stored. Is this > intentional?
Yes, but only in the same sense that most of our libmesh_not_implemented() calls are intentional - better to provide partial support for a feature than no support at all. > It looks like boundary_info is intended to be able to store multiple > boundary condition IDs per side. Definitely. > Attached is a patch that packs up all of the IDs associated with each > side. The code to read in the serialized data does not appear to > require any changes. Did you really managed to get overlapping BC IDs working with a dozen-line patch? Egg on our faces... I don't think any of the primary developers use multiple IDs on the same boundary right now, but if we'd known it would be that simple to support the I/O we'd have done it years ago. I don't see any obvious problems with this patch in the multiple ID case and it looks like it degenerates to the existing behavior in the single ID case, so I'll commit it now. We really ought to get a test for this into the examples or unit tests too... it's the sort of underused feature that's easy to regress. Thanks, --- Roy ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
