From: Roy S. <roy...@ic...> - 2008-12-10 18:27:01
|
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. --- Roy |
From: Benjamin K. <ben...@na...> - 2008-12-10 18:38:55
|
> 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 |
From: Roy S. <roy...@ic...> - 2008-12-10 18:59:46
|
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 |
From: Roy S. <roy...@ic...> - 2008-12-10 19:54:26
|
On Wed, 10 Dec 2008, Roy Stogner wrote: > 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. Hmm... for right now, I think all I'm going to do is fix BoundaryInfo::add_side() to avoid adding the *same* id to the same side twice. That will still allow other users to add different ids to the same side, it'll be enough to avoid the XdrIO bug for my problems, and it'll be a much quicker fix than deciding what the right API for multi-id sides is. --- Roy |
From: Roy S. <roy...@ic...> - 2008-12-10 19:04:53
|
On Wed, 10 Dec 2008, Roy Stogner wrote: > We'd still need to make some major changes to make that work, though: Oh, and by "major changes" I may even mean "impossible changes". Obviously our XDR/XDA-based format will handle multiple IDs per side just fine after a bugfix or two in the read/write code, but do the other mesh formats we're using have the same capability? "Handle overlapping boundary conditions with bit fields" is a hack, but it's a hack that beats "remember which I/O formats don't support overlapping boundary conditions and avoid them". Hopefully I'm just being overly paranoid, though; do Exodus/etc. support multiple IDs per side? --- Roy |
From: Derek G. <fri...@gm...> - 2008-12-10 19:39:40
|
On Dec 10, 2008, at 12:04 PM, Roy Stogner wrote: > Hopefully I'm just being overly paranoid, though; do Exodus/etc. > support multiple IDs per side? The answer is yes: Exodus does support more than one side id per side. In reality it's not a side ID per say... but rather lists of sides... or sidesets that are associated with numbers. The same side can be included in multiple sidesets. That said... I don't envision ever using this capability. What we do now is associate boundary conditions with boundary ids. We can associate any number of boundary conditions with a side id... which takes care of the case that Ben was mentioning. Essentially the ID or number itself doesn't mean anything in particular... we just use it to get the list of boundary conditions active on that side. With that scheme there is never a reason to assign more than one ID to a side.... you can always just make any "overlap" region it's own boundary_id and apply both boundary conditions on that boundary id. In Sierra they _did_ utilize this capability from time to time... but it was really more of a convenience. Derek |