On 04/08/2013 11:59 AM, Roy Stogner wrote: > > On Mon, 8 Apr 2013, David Knezevic wrote: > >> I have a use-case where it'd be helpful to store multiple subdomain IDs >> on elements (similar to what we do for boundary IDs now). >> >> The first thing that comes to mind is changing Elem to store a >> std::set<subdomain_id_type>, would that be of interest in general? > > Opposing that would probably be of interest in general. We typically > have sizeof(subdomain_id_type)==2; squeezing even a couple pointers in > there would lead to megabytes of extra RAM use on large problems. The > boundary is generally a "cheaper" case since a problem with a million > elements is likely to only have ~50,000 boundary elements, and only a > fraction of those are on the coarse grid.
Yep, agreed. I figured that since we have multiple IDs in the boundary case it might be of interest in the subdomain case too. But yes, the extra memory for the boundary IDs isn't such a big deal... I can make user code (as Ben suggested) that'll work for me case with the single subdomain setup (I might do some bitwise AND'ing of subdomain IDs with "masks") David ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
