On 18 February 2013 21:36, Mark F. Adams <mark.adams at columbia.edu> wrote: > > On Feb 18, 2013, at 4:00 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > Hmm, this debugging check was added by Mark here. > > https://bitbucket.org/petsc/petsc-dev/commits/fb7e4343253b73d3fb40857991a8c6d5d0c7c56b#Lsrc/mat/impls/aij/mpi/mmaij.cT126 > > > The logic here is messed up. Valid input could result in a non-collectiv > result. So this DEBUG code should be a real check here. I think the logic > is OK to detect a blocked garray locally ? but some processors could be > proper and others not as Jed pointed out. > > Barry touched the code a bit earlier to add this case: > > https://bitbucket.org/petsc/petsc-dev/commits/c997baff1558fd165412be034e812bb69f90972a > > Prior to that, Mark had reversed the meaning of that bit of code: > > https://bitbucket.org/petsc/petsc-dev/commits/a85625d104df12863d7d1735f9fdbe9b281ef7d2#chg-src/mat/impls/aij/mpi/mmaij.c > > Even in Barry's original code, I don't understand why we can expect this > check to be producing a collective result. Surely there can be some ranks > that see everything evenly divide and others that do not. > > It seems to me that we should either (a) explicitly disallow matrices with a > block size to be built when the blocks are not filled or (b) when the user > requests blocks, pad blocks so that we can always use an ISBlock. > > > It looks like we have (a) now in a debug build. I'm not wild about (b), > this is only used to use blocked IS for efficiency and we have never measure > that this is useful. > > So I will comment out the whole 'useblockis' business and let Garth move > along. We could do an all reduce to see if everyone is blocked and then, > and only then, use th blocked ISs. This would cost an alreduce. Not sure > what would be better, but for now we can just disable this. >
Thanks. Works now. Garth > > On Mon, Feb 18, 2013 at 2:35 PM, Garth N. Wells <gnw20 at cam.ac.uk> wrote: >> >> I have some code using ML as a preconditioner, and it works fines >> with PETSc 3.3 but crashes with PETSc dev. I'm not setting any of the >> ML parameters. Hopefully someone will recognise the error (below) and >> save me having to bisect the changesets, which is hard because changes >> in PETSc dev make it hard for me to compile against earlier PETSc dev >> revisions. >> >> Garth >> >> >> [0]PETSC ERROR: --------------------- Error Message >> ------------------------------------ >> [0]PETSC ERROR: Petsc has generated inconsistent data! >> [0]PETSC ERROR: Use of blocked not consistant (I am usning blocked)! >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: Petsc Development HG revision: >> 96a09d6a701823d69aede247ed949c1dd4e7c8ff HG Date: Mon Feb 18 11:08:29 >> 2013 -0600 >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >> [0]PETSC ERROR: See docs/index.html for manual pages. >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: Unknown Name on a arch-linux2-c-debug named ....... >> Mon Feb 18 19:25:17 2013 >> [0]PETSC ERROR: Libraries linked from /home/garth/local/gcc/petsc-dev/lib >> [0]PETSC ERROR: >> [3]PETSC ERROR: See docs/index.html for manual pages. > > >
