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 ------------------------------------------------------------------------------ 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
