April 2016 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] technical C question
by Satish Balay 07 Apr '16

07 Apr '16

On Thu, 7 Apr 2016, Jed Brown wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > Should we caste to an unsigned PetscInt first then? > > It should be unsigned, yes. Does that fix the warning? Nope.. Commenting out the following line - or changing the argument thus is making a difference. diff --git a/src/mat/impls/baij/seq/baijfact.c b/src/mat/impls/baij/seq/baijfact.c index fea37cb..e2c210c 100644 --- a/src/mat/impls/baij/seq/baijfact.c +++ b/src/mat/impls/baij/seq/baijfact.c @@ -1081,7 +1081,7 @@ PetscErrorCode MatICCFactorSymbolic_SeqBAIJ(Mat fact,Mat A,IS perm,const MatFact ncols_upper++; } } - ierr = PetscIncompleteLLAdd(ncols_upper,cols,levels,cols_lvl,am,nlnk,lnk,lnk_lvl,lnkbt);CHKERRQ(ierr); + ierr = PetscIncompleteLLAdd(ncols,cols,levels,cols_lvl,am,nlnk,lnk,lnk_lvl,lnkbt);CHKERRQ(ierr); nzk += nlnk; /* update lnk by computing fill-in for each pivot row to be merged in */ Changing PetscIncompleteLLAdd() to PetscIncompleteLLAddSorted() doesn't make a difference. Or the following change is also making a difference. [but not 'i=ncols_upper' nor 'i=ncols_upper-2'] i = ncols_upper-3; ierr = PetscIncompleteLLAdd(i,cols,levels,cols_lvl,am,nlnk,lnk,lnk_lvl,lnkbt);CHKERRQ(ierr); I don't really understand this [why ncols_upper is triggering this]. Satish

1 0

Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2016-04-07
by Barry Smith 07 Apr '16

07 Apr '16

Dave, It is only a "guess" at who is blame for a particular fault. It could easily be a different commit or different person who introduced the fault. In this case you can just ignore it. Barry > On Apr 7, 2016, at 4:50 PM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > I don't fully understand this report. > > Commits related to PCSemiRedundant involved a file called sred_dmda.c, yet the warning is associated with telescope_dmda.c > > Does the report imply that code generating these warnings was always present from the initial commit. Given the filename changed and a lot of things were altered in this file (now called telescope_dmda.c) I'm surprised that the warning can be traced all the way back to the first commit. > > > > On 7 April 2016 at 16:00, PETSc checkBuilds <petsc-checkbuilds(a)mcs.anl.gov> wrote: > > > Dear PETSc developer, > > This email contains listings of contributions attributed to you by > `git blame` that caused compiler errors or warnings in PETSc automated > testing. Follow the links to see the full log files. Please attempt to fix > the issues promptly or let us know at petsc-dev(a)mcs.anl.gov if you are unable > to resolve the issues. > > Thanks, > The PETSc development team > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/36501ec > PCSemiRedundant: > > src/ksp/pc/impls/telescope/telescope_dmda.c:1001 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:1001:12: warning: Function call argument is an uninitialized value > > src/ksp/pc/impls/telescope/telescope_dmda.c:154 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:154:11: warning: Assigned value is garbage or undefined > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/6ab51f8 > PCSemiRedundant: > > src/ksp/pc/impls/telescope/telescope.c:193 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope.c:193:9: warning: Dereference of undefined pointer value > > src/ksp/pc/impls/telescope/telescope.c:206 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope.c:206:12: warning: Function call argument is an uninitialized value > > src/ksp/pc/impls/telescope/telescope_dmda.c:254 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:254:11: warning: Assigned value is garbage or undefined > > src/ksp/pc/impls/telescope/telescope_dmda.c:854 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:854:9: warning: Dereference of undefined pointer value > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/f650675 > PCTelescope: > > src/ksp/pc/impls/telescope/telescope_dmda.c:867 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_…] > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:867:12: warning: Function call argument is an uninitialized value > > ---- > To opt-out from receiving these messages - send a request to petsc-dev(a)mcs.anl.gov. >

1 0

Re: [petsc-dev] PETSc blame digest (next) 2016-04-07
by Dave May 07 Apr '16

07 Apr '16

I don't fully understand this report. Commits related to PCSemiRedundant involved a file called sred_dmda.c, yet the warning is associated with telescope_dmda.c Does the report imply that code generating these warnings was always present from the initial commit. Given the filename changed and a lot of things were altered in this file (now called telescope_dmda.c) I'm surprised that the warning can be traced all the way back to the first commit. On 7 April 2016 at 16:00, PETSc checkBuilds <petsc-checkbuilds(a)mcs.anl.gov> wrote: > > > Dear PETSc developer, > > This email contains listings of contributions attributed to you by > `git blame` that caused compiler errors or warnings in PETSc automated > testing. Follow the links to see the full log files. Please attempt to fix > the issues promptly or let us know at petsc-dev(a)mcs.anl.gov if you are > unable > to resolve the issues. > > Thanks, > The PETSc development team > > ---- > > warnings attributed to commit > https://bitbucket.org/petsc/petsc/commits/36501ec > PCSemiRedundant: > > src/ksp/pc/impls/telescope/telescope_dmda.c:1001 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:1001:12: > warning: Function call argument is an uninitialized value > > src/ksp/pc/impls/telescope/telescope_dmda.c:154 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:154:11: > warning: Assigned value is garbage or undefined > > ---- > > warnings attributed to commit > https://bitbucket.org/petsc/petsc/commits/6ab51f8 > PCSemiRedundant: > > src/ksp/pc/impls/telescope/telescope.c:193 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope.c:193:9: > warning: Dereference of undefined pointer value > > src/ksp/pc/impls/telescope/telescope.c:206 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope.c:206:12: > warning: Function call argument is an uninitialized value > > src/ksp/pc/impls/telescope/telescope_dmda.c:254 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:254:11: > warning: Assigned value is garbage or undefined > > src/ksp/pc/impls/telescope/telescope_dmda.c:854 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:854:9: > warning: Dereference of undefined pointer value > > ---- > > warnings attributed to commit > https://bitbucket.org/petsc/petsc/commits/f650675 > PCTelescope: > > src/ksp/pc/impls/telescope/telescope_dmda.c:867 > [ > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > ] > > /sandbox/petsc/petsc.clone/src/ksp/pc/impls/telescope/telescope_dmda.c:867:12: > warning: Function call argument is an uninitialized value > > ---- > To opt-out from receiving these messages - send a request to > petsc-dev(a)mcs.anl.gov. >

1 0

Re: [petsc-dev] technical C question
by Jed Brown 07 Apr '16

07 Apr '16

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Should we caste to an unsigned PetscInt first then? It should be unsigned, yes. Does that fix the warning?

1 0

Re: [petsc-dev] technical C question
by Barry Smith 07 Apr '16

07 Apr '16

> On Apr 7, 2016, at 2:37 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> the clang static code analyzer reports >> >> In file included from /sandbox/petsc/petsc.clone/include/petsc/private/matimpl.h:1233: >> /sandbox/petsc/petsc.clone/include/petscbt.h:85:36: warning: The result of the '<<' expression is undefined >> BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), >> ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Is the code wrong/unnecessary or clang? > > I would guess it is complaining about C99 §6.5.7.3: > > If the value of the right operand is negative or is greater than or > equal to the width of the promoted left operand, the behavior is > undefined. Should we caste to an unsigned PetscInt first then?

1 0

Re: [petsc-dev] Need help with Fortran code/compiler issue
by Jeff Hammond 07 Apr '16

07 Apr '16

In my experience, "-Wmaybe-uninitialized" is a great way to generate false positive compiler warnings and nothing else. Jeff On Thu, Apr 7, 2016 at 11:46 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > src/sys/classes/bag/f2003-src/fsrc/bagenum.F has the code fragment > > Subroutine PetscBagRegisterEnum(bag,addr,FArray,def,n,h,ierr) > use,intrinsic :: iso_c_binding > implicit none > > PetscBag bag > character(*) n,h > character(*) FArray(*) > PetscEnum :: def > PetscErrorCode,intent(out) :: ierr > PetscReal addr(*) > > Type(C_Ptr),Dimension(:),Pointer :: CArray > character(kind=c_char),pointer :: nullc => null() > PetscInt :: i,Len > Character(kind=C_char,len=256),Dimension(:),Pointer::list1 > > do i=1,256 > if (len_trim(Farray(i)) .eq. 0) then > Len = i-1 > goto 100 > endif > if (len_trim(Farray(i)) .gt. 255) then > ierr = PETSC_ERR_ARG_OUTOFRANGE > return > endif > enddo > ierr = PETSC_ERR_ARG_OUTOFRANGE > return > > 100 continue > > Allocate(list1(Len),stat=ierr); > Allocate(CArray(Len+1),stat=ierr) > do i=1,Len > list1(i) = trim(FArray(i))//C_NULL_CHAR > enddo > > CArray = (/(c_loc(list1(i)),i=1,Len),c_loc(nullc)/) > call PetscBagRegisterEnumPrivate(bag,addr,CArray,def,n,h,ierr) > DeAllocate(CArray) > DeAllocate(list1) > End Subroutine > > which produces the following warning with one Fortran compiler: > > > /Users/petsc/petsc.clone-4/src/sys/objects/f2003-src/fsrc/optionenum.F:35:0: > > CArray = (/(c_loc(list1(i)),i=1,Len),c_loc(nullc)/) > ^ > Warning: 'list1.data' may be used uninitialized in this function > [-Wmaybe-uninitialized] > > Do any Fortran programmers know if the code is correct or if this is an > incorrect warning from the compiler? > > Thanks > > Barry > > > > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [petsc-dev] technical C question
by Jed Brown 07 Apr '16

07 Apr '16

Barry Smith <bsmith(a)mcs.anl.gov> writes: > the clang static code analyzer reports > > In file included from /sandbox/petsc/petsc.clone/include/petsc/private/matimpl.h:1233: > /sandbox/petsc/petsc.clone/include/petscbt.h:85:36: warning: The result of the '<<' expression is undefined > BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), > ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Is the code wrong/unnecessary or clang? I would guess it is complaining about C99 §6.5.7.3: If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.

1 0

Re: [petsc-dev] technical C question
by Matthew Knepley 07 Apr '16

07 Apr '16

On Thu, Apr 7, 2016 at 2:28 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > We have code > > return (BT_idx = index/PETSC_BITS_PER_BYTE, > BT_c = array[BT_idx], > BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), > array[BT_idx] = (char)(BT_c | BT_mask), > (char)(BT_c & BT_mask)); > > inside > > petscbt.h > > the clang static code analyzer reports > > In file included from > /sandbox/petsc/petsc.clone/include/petsc/private/matimpl.h:1233: > /sandbox/petsc/petsc.clone/include/petscbt.h:85:36: warning: The result of > the '<<' expression is undefined > BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), > ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Is the code wrong/unnecessary or clang? > It looks right to me: index%PETSC_BITS_PER_BYTE gives the offset of this bit in the current byte. 1 << index%PETSC_BITS_PER_BYTE Gives an int with a 1 at the offset'th bit, and then we cast to a char. I have no idea why clang complains. Matt > Thanks > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

technical C question
by Barry Smith 07 Apr '16

07 Apr '16

We have code return (BT_idx = index/PETSC_BITS_PER_BYTE, BT_c = array[BT_idx], BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), array[BT_idx] = (char)(BT_c | BT_mask), (char)(BT_c & BT_mask)); inside petscbt.h the clang static code analyzer reports In file included from /sandbox/petsc/petsc.clone/include/petsc/private/matimpl.h:1233: /sandbox/petsc/petsc.clone/include/petscbt.h:85:36: warning: The result of the '<<' expression is undefined BT_mask = (char)(1 << index%PETSC_BITS_PER_BYTE), ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is the code wrong/unnecessary or clang? Thanks

1 0

Re: [petsc-dev] Correct syntax for DMDA ownership ranges in petsc4py
by Matthew Knepley 07 Apr '16

07 Apr '16

On Thu, Apr 7, 2016 at 2:14 PM, Chris Eldred <chris.eldred(a)gmail.com> wrote: > I think what happens on the 1st version is that the input list has > len(3), and since the DMDA only has 1 dimension petsc4py throws the > first ValueError. > Yes, you are right. > As far as I can tell, the code is expecting a list of lists: ie for > each dimension it gets ranges[i] (where i is the index for the > dimension) and casts it into an array. So I tried the 2nd version, > which fails regardless of whether I use lists or tuples, and I don't > understand why. That function returns 'range' and the type is declared as tuple. Did you try ownership_ranges=((8,8,4),) Matt > > -Chris > > On Thu, Apr 7, 2016 at 9:00 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Apr 7, 2016 at 1:52 PM, Chris Eldred <chris.eldred(a)gmail.com> > wrote: > >> > >> Hey All, > >> > >> (I sent this to petsc-users a few days ago and didn't get any replies, > >> figured I would try here as well...) > >> > >> Does anyone know the correct syntax for setting ownership ranges for > >> DMDAs in petsc4py? For example, if I have a 1D DMDA with 20 vertices > >> and 3 processes, and I want to distribute the vertices as [8,8,4], > >> should the correct create call be: > >> > >> da = > >> > PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], > >> stencil_type= PETSc.DMDA.StencilType.BOX, > >> stencil_width=1,ownership_ranges=[8,8,4]) > >> > >> or > >> > >> da = > >> > PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], > >> stencil_type= PETSc.DMDA.StencilType.BOX, > >> stencil_width=1,ownership_ranges=[[8,8,4],]) > >> > >> For me, the 1st version fails with > >> ValueError: number of dimensions 1 and number ownership ranges 3 > >> (which I expected) > >> but the 2nd version also fails with > >> TypeError: Expected tuple, got list > >> > >> I have tried using tuples instead of lists and nothing changes. > >> Creating without the ownership_ranges argument works fine as well. Is > >> there something else I am missing? > > > > > > Here is the code: > > > > > > > https://bitbucket.org/petsc/petsc4py/src/b234a50085607b793fce93d5dc46307c0d… > > > > I do not understand why the 1st version fails. > > > > Matt > > > >> > >> Thanks in advance for any assistance! > >> > >> Regards, > >> -Chris > >> > >> > >> -- > >> Chris Eldred > >> Postdoctoral Fellow, LAGA, University of Paris 13 > >> PhD, Atmospheric Science, Colorado State University, 2015 > >> DOE Computational Science Graduate Fellow (Alumni) > >> B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > >> chris.eldred(a)gmail.com > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > experiments > > is infinitely more interesting than any results to which their > experiments > > lead. > > -- Norbert Wiener > > > > -- > Chris Eldred > Postdoctoral Fellow, LAGA, University of Paris 13 > PhD, Atmospheric Science, Colorado State University, 2015 > DOE Computational Science Graduate Fellow (Alumni) > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred(a)gmail.com > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0