Wow, If this does indeed fix the issue, then I can think of a lot of memory hog areas in MOOSE that we might have to cleanup sooner rather than later.  I hope the overhead of the tree doesn't dominate the value_type stored so much that it blows us up our total usage by 200%!  On the other hand sizeof(std::pair<Elem*, dof_id_type>) is probably about half that of a single node in the equivalent red/black tree when you consider the left right pointers... yikes!

Cody 


On Wed, Oct 30, 2013 at 2:41 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk@nasa.gov> wrote:
Back to the subject issue of Metis memory usage -

https://github.com/libMesh/libmesh/blob/master/src/partitioning/metis_partitioner.C#L105

We build a std::map<> from Elem* to a unique sorted contiguous ID, as Metis only considers the active elements and needs some contiguous numbering. I expect that gets quite big, and maybe should be refactored to use a sorted std::vector<std::pair<Elem*, dof_id_type> > instead?

We could build it in one pass, sort it, and then use it with a binary search or something.

-Ben


------------------------------------------------------------------------------
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