On Wed, Oct 30, 2013 at 3:09 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> 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
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
