From: Roy S. <roy...@ic...> - 2011-05-18 18:38:11
|
Currently when we sync a BoundaryMesh for the entire boundary, we give the boundary elements subdomain_ids and processor_ids that correspond (after mapping them to be sequential starting with 0) to the boundary condition ids their corresponding interior elements' sides had... unless we're sync'ing a limited set of requested boundary ids, in which case we make the subdomain_ids and processor_ids match the interior elements. Would anyone mind if we just made the latter behavior the default for *any* BoundaryInfo::sync? The former seems kind of useless, except maybe for visualization-only purposes, and it would be nice to refactor the two implementations, since adding ParallelMesh support is making the sync() a bit more complicated. --- Roy |
From: John P. <jwp...@gm...> - 2011-05-18 18:42:08
|
On Wed, May 18, 2011 at 12:37 PM, Roy Stogner <roy...@ic...> wrote: > > Currently when we sync a BoundaryMesh for the entire boundary, we give > the boundary elements subdomain_ids and processor_ids that correspond > (after mapping them to be sequential starting with 0) to the boundary > condition ids their corresponding interior elements' sides had... > unless we're sync'ing a limited set of requested boundary ids, in > which case we make the subdomain_ids and processor_ids match the > interior elements. > > Would anyone mind if we just made the latter behavior the default for > *any* BoundaryInfo::sync? The former seems kind of useless, except > maybe for visualization-only purposes, and it would be nice to > refactor the two implementations, since adding ParallelMesh support is > making the sync() a bit more complicated. Sounds good to me. I think that code was mostly for viewing boundary IDs in GMV on Boundary meshes. Since GMV is dead, this feature is probably not of much current use. -- John |
From: Roy S. <roy...@ic...> - 2011-05-18 19:01:17
|
On Wed, 18 May 2011, John Peterson wrote: > On Wed, May 18, 2011 at 12:37 PM, Roy Stogner <roy...@ic...> wrote: >> >> Currently when we sync a BoundaryMesh for the entire boundary, we give >> the boundary elements subdomain_ids and processor_ids that correspond >> (after mapping them to be sequential starting with 0) to the boundary >> condition ids their corresponding interior elements' sides had... >> unless we're sync'ing a limited set of requested boundary ids, in >> which case we make the subdomain_ids and processor_ids match the >> interior elements. >> >> Would anyone mind if we just made the latter behavior the default for >> *any* BoundaryInfo::sync? The former seems kind of useless, except >> maybe for visualization-only purposes, and it would be nice to >> refactor the two implementations, since adding ParallelMesh support is >> making the sync() a bit more complicated. > > Sounds good to me. I think that code was mostly for viewing boundary > IDs in GMV on Boundary meshes. > > Since GMV is dead, this feature is probably not of much current use. That is a nice feature to be able to have, though. We ought to be able to view subdomain ids with more than just GMV. And Vikram's IMing me to tell me he still does this kind of viz (but could live without it). >From a code point of view it's no big deal either way - get the interior parent of your element and you can get the subdomain id or boundary ids from that. But for visualization, copying boundary ids to subdomain ids would be much more convenient to use... *except* that there's a catch: libMesh supports sets of boundary ids on each side, but only supports a single boundary id on each element. I don't know if anyone's actually using any code that has overlapping boundary ids, but whenever I run across library code that interferes with such usage I've been trying to fix it. I cring at adding *new* code that makes a "one boundary id per boundary side" assumption. We could always add support for overlapping subdomain ids... but Ben just got finished trimming down mesh memory usage and consolidating heap allocation; it would feel cruel to add another several bytes per element for a brand-new indirection layer that most people would never use. --- Roy |
From: Derek G. <fri...@gm...> - 2011-05-18 19:14:47
|
First: I don't use BoundaryMesh... so go wild.... On May 18, 2011, at 1:01 PM, Roy Stogner wrote: >> From a code point of view it's no big deal either way - get the > interior parent of your element and you can get the subdomain id or > boundary ids from that. But for visualization, copying boundary ids > to subdomain ids would be much more convenient to use... *except* that > there's a catch: libMesh supports sets of boundary ids on each side, > but only supports a single boundary id on each element. I don't know > if anyone's actually using any code that has overlapping boundary ids, Us. We use it _extensively_, as in... every simulation. > We could always add support for overlapping subdomain ids... but Ben > just got finished trimming down mesh memory usage and consolidating > heap allocation; it would feel cruel to add another several bytes per > element for a brand-new indirection layer that most people would never > use. It would be cruel... BUT, I had a user in my office just yesterday that wanted to have overlapping subdomains. I think for now we're going to deal with it using an external file that defines the overlaps and deal with it manually... but there could be a better way. One issue is that Exodus doesn't support elements being in more than one block at the same time. In fact... if you try to do that it will look like they are _two_ elements that just happen to be in the same spot (and connected to the same nodes)! Certainly not ideal. There is a way around that though: Exodus does have some metadata that you can define for each element. We could finally take the step of disassociating "block" from "subdomain_id"... and instead read subdomain_id out of some of the metadata. This would help us in the case of mixed element types in the same subdomain as well (because the elements could go into different "blocks" but have the same subdomain metadata). The trouble is that this won't be very compatible with Paraview/Ensight/Visit.......... and that's a big gotcha. I don't think there is any great answer here... Derek |
From: Roy S. <roy...@ic...> - 2011-05-18 19:48:55
|
On Wed, 18 May 2011, Derek Gaston wrote: > On May 18, 2011, at 1:01 PM, Roy Stogner wrote: > >> From a code point of view it's no big deal either way - get the >> interior parent of your element and you can get the subdomain id or >> boundary ids from that. But for visualization, copying boundary ids >> to subdomain ids would be much more convenient to use... *except* that >> there's a catch: libMesh supports sets of boundary ids on each side, >> but only supports a single boundary id on each element. I don't know >> if anyone's actually using any code that has overlapping boundary ids, > > Us. We use it _extensively_, as in... every simulation. Good to hear. The one aspect to that support that I'd feared might be lacking is I/O. Does that work for visualizing boundary ids as well? >> We could always add support for overlapping subdomain ids... but Ben >> just got finished trimming down mesh memory usage and consolidating >> heap allocation; it would feel cruel to add another several bytes per >> element for a brand-new indirection layer that most people would never >> use. > > It would be cruel... BUT, I had a user in my office just yesterday > that wanted to have overlapping subdomains. I think for now we're > going to deal with it using an external file that defines the > overlaps and deal with it manually... but there could be a better > way. We could do fancy things with copy-on-write here (more easily if we replaced the non-const subdomain_id() with a straightforward setter method) to keep the costs from getting too out of hand. I'd be willing to write the guts if you'd handle the Exodus/Nemesis support. I think whatever we do would at least have to replace that _sbd_id char with a full pointer... On the other hand, if we're really worried about every 8 bytes, there's a handful of little optimizations that we could do but haven't yet. Consolidating _children and _parent pointers into the same array as _neighbors would free up at least 16 bytes per element right off the bat. > One issue is that Exodus doesn't support elements being in more than > one block at the same time. In fact... if you try to do that it > will look like they are _two_ elements that just happen to be in the > same spot (and connected to the same nodes)! Certainly not ideal. > > There is a way around that though: Exodus does have some metadata > that you can define for each element. We could finally take the > step of disassociating "block" from "subdomain_id"... and instead > read subdomain_id out of some of the metadata. This would help us > in the case of mixed element types in the same subdomain as well > (because the elements could go into different "blocks" but have the > same subdomain metadata). That would be very nice. > The trouble is that this won't be very compatible with > Paraview/Ensight/Visit.......... and that's a big gotcha. Define incompatible for me? They won't be able to visualize the subdomains? Or they won't be able to open the files as all? > I don't think there is any great answer here... For the original problem, I think I'm settling on "boundary element subdomain id == interior element boundary condition id". That'll at least avoid breaking anyone's bcid viz, and there's no real downside other than that it rubs my nose in an existing problem. --- Roy |
From: Derek G. <fri...@gm...> - 2011-05-18 20:22:01
|
On May 18, 2011, at 1:48 PM, Roy Stogner wrote: > Good to hear. The one aspect to that support that I'd feared might be > lacking is I/O. > > Does that work for visualizing boundary ids as well? Visualizing boundary ids is simple... just use Paraview or Ensight. Ensight is great... it colors your boundaries by the boundary ids... and you can see where they overlap. In Paraview just turn off all the blocks and turn on sidesets (usually one at a time so you can see what each one contains). Both programs also allow you to draw the sidesets and paint solution variables on them (and displace them, etc.). No reason to do the whole BoundaryMesh thing at all for visualization. >> It would be cruel... BUT, I had a user in my office just yesterday >> that wanted to have overlapping subdomains. I think for now we're >> going to deal with it using an external file that defines the >> overlaps and deal with it manually... but there could be a better >> way. > > We could do fancy things with copy-on-write here (more easily if we > replaced the non-const subdomain_id() with a straightforward setter > method) to keep the costs from getting too out of hand. I'd be > willing to write the guts if you'd handle the Exodus/Nemesis support. I'm not exactly following you here... > I think whatever we do would at least have to replace that _sbd_id > char with a full pointer... > > On the other hand, if we're really worried about every 8 bytes, > there's a handful of little optimizations that we could do but > haven't yet. Consolidating _children and _parent pointers into the > same array as _neighbors would free up at least 16 bytes per element > right off the bat. >> The trouble is that this won't be very compatible with >> Paraview/Ensight/Visit.......... and that's a big gotcha. > > Define incompatible for me? They won't be able to visualize the > subdomains? Or they won't be able to open the files as all? Wouldn't be able to visualize the subdomains. In particular you wouldn't be able to "turn off" or "hide" subdomains. That is a VERY important feature that we use ALL the time (because we have models with multiple "layers" in subdomains that are surrounding each other... so it is great to be able to turn off an outside "layer" to see an inside layer.... and no, a slice doesn't always cut it (pun!). >> I don't think there is any great answer here... > > For the original problem, I think I'm settling on "boundary element > subdomain id == interior element boundary condition id". That'll at > least avoid breaking anyone's bcid viz, and there's no real downside > other than that it rubs my nose in an existing problem. Sounds fine... but like I say there are better ways to do boundary visualization these days.... Derek |
From: Roy S. <roy...@ic...> - 2011-05-25 18:25:00
|
On Wed, 18 May 2011, Derek Gaston wrote: >>> It would be cruel... BUT, I had a user in my office just yesterday >>> that wanted to have overlapping subdomains. I think for now we're >>> going to deal with it using an external file that defines the >>> overlaps and deal with it manually... but there could be a better >>> way. >> >> We could do fancy things with copy-on-write here (more easily if we >> replaced the non-const subdomain_id() with a straightforward setter >> method) to keep the costs from getting too out of hand. I'd be >> willing to write the guts if you'd handle the Exodus/Nemesis support. > > I'm not exactly following you here... "fancy things with copy-on-write": the collection (probably a std::vector, but conceptually a set) of subdomain ids on one element will be the exact same as the collection of subdomain ids on any other elements in the same intersection of subdomains, and there are likely to be many of those. So we don't store the collection once per element, we store it once per unique subdomain intersection in a sort of singleton reference counted unsorted_map-of-collections, and each element just stores a pointer to their collection. Then when the element wants to add or remove a subdomain, we see if the corresponding new collection exists yet, and if not we create it, and we reset the element's pointer to the new collection. So the per-element cost is always 8 bytes, just so long as the number of unique subdomain intersections doesn't scale with the number of elements. "willing to write the guts": I'd make the new subdomain setter/getter methods work this way and make the old methods compatible. "if you'd handle the Exodus/Nemesis support": I hate writing I/O even when I *do* intimately know the file format... ;-) >>> The trouble is that this won't be very compatible with >>> Paraview/Ensight/Visit.......... and that's a big gotcha. >> >> Define incompatible for me? They won't be able to visualize the >> subdomains? Or they won't be able to open the files as all? > > Wouldn't be able to visualize the subdomains. In particular you > wouldn't be able to "turn off" or "hide" subdomains. That is a VERY > important feature that we use ALL the time (because we have models > with multiple "layers" in subdomains that are surrounding each > other... so it is great to be able to turn off an outside "layer" to > see an inside layer.... and no, a slice doesn't always cut it > (pun!). Hmm... we could make each unique subdomain intersection into its own Exodus block (well, group of exodus blocks if different element types share the same subdomain intersection). It'd be a PITA for viz users to have to turn off subdomain 5 by "first turn off 5-alone, then turn off 5-intersect-4, then turn off 5-intersect-6..." but that might still be an improvement over "5-intersect-4 and 5-intersect-6 aren't supported". --- Roy |