From: John P. <jwp...@gm...> - 2013-10-30 21:28:30
|
On Wed, Oct 30, 2013 at 3:09 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Yeah, before I get too carried away I should probably just try running the > existing code path twice: Once as-is, and again actually commenting out > the underlying Metis call, making the partitioner a big, expensive no-op. > > Actually, John, if you have a chance could you rerun one of the cases you > have data for, but just comment out the call to metis? Hopefully the > memory usage will drop, verifying metis is the issue. > > It should suffice to comment out the metis call, and add a > > std::fill (part.begin(), part.end(), 0); > > instead, provided its this simple stand-alone case where the mesh is not > used! > Yep, I can certainly do that, but I think this is already verified just by looking at the difference in memory usage between Centroid/Linear/SFC Paritioner and Metis I posted in one of the prior emails this week. Switching from std::map to a sorted vector sounds like a good idea... especially considering the use case here. I was also wondering about the size of the std::vector<std::vector<dof_id_type> > graph(n_active_elem); that gets temporarily created... it should be approximately n_active_elem * n_neighbors * sizeof(unsigned) in size, but maybe that still pales in comparison to the std::map... -- John |