On Wed, 1 Jun 2011, Cody Permann wrote: > We (the INL) have the need to grow the number of subdomains in our > simulations past the current storage capacity of subdomain_id_type. > This type is currently set as an unsigned char allowing only 256 > subdomains. We are already starting to run and debug libMesh using > a locally patched version allowing a storage size of 16 bits. I > wanted to see what thoughts the other developers have to growing > this type permanently to 16 bits. Should we make a new configure > option to allow us to change the default size? Should we just make > the change to the library?
My personal preference would be to have it default to 8 bits, but configurable to 16 bits with --enable-16bit-subdomain-ids and/or --enable-everything. Default to 16 bits but configurable to --enable-8bit-subdomain-ids would be fine if enough people disagree with me. If you're futzing around with configuring data sizes and want to make processor_id_type configure-time expandable that might be nice too. > Are there other issues/concerns with changing this type? I'm pretty sure we'll break if it goes above 32 bits. (but it actually might work at 32 bits too, if you want to add a non-default option for that) Struct padding in elem.h is such that adding 1 byte to sizeof(subdomain_id_type) won't necessarily add 1 byte to sizeof(Elem). At first glance it looks like it would add 4 bytes on 32-bit systems or 0 bytes on 64-bit systems, but I wouldn't swear to any of that. --- Roy ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
