I just checked out the hash immediately prior to the latest Metis/Parmetis refresh (git co 5771c42933), ran the same tests again, and got basically the same results on the 200^3 case.So I don't think the metis/parmetis refresh introduced any new memory bugs...Just for the hell of it, I also tried some other problem sizes, and in going from 1 core to 2 cores (Metis off to Metis on) the memory usage per core always increases (to within the accuracy of Activity Monitor) by a factor between 1.5 and 1.9:100^3: 300 -> 500 Mb/core (1.67X)150^3: 975 ->1700 Mb/core (1.75X)175^3: 1.5 -> 2.8 Gb/core (1.87X)200^3: 2.22 -> 4 Gb/core (1.80X)225^3: 3.15 -> 4.75 Gb/core (1.5X)
We have a more fine-grained memory checker tool here that I'm going to try in a bit, and I'm also going to try the same tests with ParallelMesh/Parmetis.
Ben, it looks like we currently base our partitioning algorithm choice solely on the number of partitions... Do you recall if PartGraphKway is any more memory efficient than the PartGraphRecursive algorithm? If so, perhaps we could base our algorithm choice on the size of the mesh requested as well as the number of partitions... I might experiment with this a bit as well.