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 ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
