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. Trying to figure out a cheaper way to do things would be nice, though... random brainstorming follows: Even with a million elements you're not likely to have more than a few thousand unique subdomain intersections. We could have a "linked web" storing those and then a single per-element pointer or index into that web. Memory management here would be scary fun. The big trouble here is I/O. We'd need a format change to store more than one integer as a subdomain id in xdr/xda, and unless you only have 64 unique subdomains, even a large integer is not going to handle the combinatorial overlapping possibilities. We've already got subdomain_id_type slightly abstracted, so my first thought was to make this a class type or a pointer-to-class type as an option, but that would break all the code, including in applications, expecting it to be an integer. We could do some metaprogramming tricks to handle configure-time switching between options gracefully. E.g. MainIDOf(subdomain_id_type id) could return id if it was an int or the first entry of a class or whatever. --- Roy ------------------------------------------------------------------------------ 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
