Jed Brown wrote: > On Mon, Nov 21, 2011 at 23:46, Andrej Mesaros <andrej.mesaros at bc.edu > <mailto:andrej.mesaros at bc.edu>> wrote: > > My code has a function which, when given a fixed matrix row index, > calculates one by one values of all non-zero matrix elements in this > row, while also returning the column index of each of these > elements. So, all I need to do is put that the 1st process has a > loop for row index going from 1 to 60k, the 2nd process has the loop > going from 60k+1 to 120k, etc. Inside the loops, the row index is > given, so it finds the non-zero elements and their column indices. > > > That is fine, but the error circumnstance indicated that a huge number > of entries were being computed by a different process. It is possible > that memory was corrupted earlier. You can try smaller problems with > valgrind or -malloc_debug -malloc_dump, but if these don't work, it > could be difficult to track down.
Given that I indeed call MatSetValues exclusively with row indices within the range determined by MatGetOwnershipRange, it should be impossible to generate entries on the wrong process, right? In such a case, could the corruption you mention be somehow due to the way I call other PETSc functions? Or is it at all possible that too small preallocation is making a problem? Also, what is the meaning of the memories in the report: "allocated", "used by process" and "requested"? Still don't understand, and couldn't find in the manual. > To clarify, is "n" the matrix dimension? So that's memory for > 100 vectors (the Krylov space) plus the memory already taken by > PETSc when assembly is done? > > > Yeah, roughly that used by PETSc plus those additional vectors needed by > SLEPc.
