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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
