Sorry, ignore the 5000^3 operation for a moment. I wrote up sample code without testing it.
In my email to Roy, I included working code that manifests the bug in a < 1M node mesh. On 10/30/2014 05:06 PM, Kirk, Benjamin (JSC-EG311) wrote: > On Oct 29, 2014, at 10:10 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > >> Actually, wait a minute. Glancing at our libHilbert code it looks >> like it's hard-coded to use 32-bit integers. That's not *necessarily* >> the end of the world (it still means using 96 bits total, there >> should be no collisions on a simple 5000^3 cube, and IIRC we have code >> for handling collisions) but it still worries me. Ben, thoughts? > Any reason you're not building the HEX27 elements directly, instead of going > from HEX8 to all_second_order()? That is surely an intensive operation. > > Along those lines though, 5000^3 HEX27 elements is actually (10,001)^3 > nodes, which is 1,000,300,030,001 nodes?! > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
