[petsc-dev] Error with ML preconditioner

Garth N. Wells gnw20 at cam.ac.uk
Mon Feb 18 16:45:52 CST 2013


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



More information about the petsc-dev mailing list