I see. Let me try that... I'm looking at example 4, which does not involve reading in a mesh. Is there a way I can parallelize even the read-in?
Thanks, Karen On Tue, Mar 9, 2010 at 5:50 PM, Roy Stogner <[email protected]>wrote: > > > On Tue, 9 Mar 2010, Karen Lee wrote: > > Thanks! Looks like I was just missing some entries of my MeshData since I >> was combining 2 node files... >> >> I'm in gdb mode and it has taken 50 min and it seems that the mesh is >> still not completely read in yet. Got stalled >> here: >> (gdb) n >> found the tetgen files to read >> read in nodes and elements >> n >> n >> n >> n >> >> after I pressed n to see if it was actually already done. Is this normal? >> (1.7M points and 11M elements... >> > > Probably. METHOD=dbg turns on a ton of debugging tests, including the > GLIBCXX tests, and last time I checked one of those tests turned some > basic std::set operations from O(log(N)) to O(N log(N)). This is > obviously a problem when N is in the millions... > > Try METHOD=devel, if you're trying to debug problems that only crop up > on large runs. You won't get the vector bounds-checking, which is a > shame, but you'll at least still be running all the libmesh_assert() > tests, and it'll run much faster. > --- > Roy > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
