On Tue, 18 Nov 2008, Benjamin Kirk wrote: > So I am looking into the size of Nodes and Elems, with an eye to adding some > state information while hopefully not increasing the size of the objects by > much (or at all).
Interesting idea, but I wonder how much overhead the inefficiencies in the default "new" allocator add. We do quite a bit of dynamic allocation for DofObject indices and Elem neighbor/node/family links. We even dynamically allocate the Nodes and Elems themselves, which I'd expect incurs a few bytes of overhead. > What has motivated this is that I would like an 'is_shared()' method in a > Node to efficiently identify nodes which are shared between processors. > (Note that testing the processor id of the node is insufficient when you own > the node.) And getting a patch around the node to look for active ghost elements isn't efficient. > 'on_boundary()' and 'has_dirichlet_bcs()' also come to mind as > something which could be useful, Shouldn't BoundaryInfo (plus any Dirichlet constraint system we eventually hack in) take care of those two? > In looking at the Elem, for example, we have two unsigned chars in there > right now for h&p refinement flags... These are used to hold one of 7 > possible values for RefinementState. I think this could be replaced with 6 > bit states (the 'DO_NOTHING' inferred from no bits set) in the case of the > h-refinement flag, and maybe 4 for the p-refinement flag. We can always interpret bits in tandem; 5 * 7 boolean states with 3 bits each is simple enough. (using 5 bits total might be excessive) > (does INACTIVE or COARSEN_INACTIVE mean anything for the > p-refinement flag?) No, they don't. > We might actually also be able to do away with the _p_level as well > if we are willing to impose some maximum p-level, say 16 or > whatever... I have a fantasy where we some day support spectral elements with FFT-based techniques to handle p in the 100s... but for now, 15 (4 bits) would be more than adequate. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
