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

Re: [petsc-dev] [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison
by Barry Smith 19 Apr '16

19 Apr '16

Jason and Alicia I have attempted to fix the --with-batch option to work properly with the various --download-xxx Could you please try your installs again with this option? Send configure.log on failure to petsc-maint(a)mcs.anl.gov Thanks Barry Technically we should always being using the --with-batch option on these machines but since the basic chip and compiler for the frontend and the nodes where the same we could get away without the --with-batch option but at the cost of "maybe being wrong". > On Apr 19, 2016, at 3:51 PM, Jason Sarich (JIRA) <jira(a)ideas-productivity.atlassian.net> wrote: > > Jason Sarich commented on <Mail Attachment.png> SDK-82 > > Re: Complete a manual test run of xSDK on Edison > Barry, > ******************************************************************************* > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): > ------------------------------------------------------------------------------- > Trilinos requires 64bit compilers! > ******************************************************************************* > I am getting this on mira as well when using --with-batch --known-mpi-shared-libraries=0 > It's trying to install trilinos before allowing me to submit the batch job. > configure.log<Mail Attachment.gif> > <Mail Attachment.png> Add Comment > > This message was sent by Atlassian JIRA (v7.2.0-OD-05-030#72002-sha1:7e8526a) > <Mail Attachment.png>

1 0

Re: [petsc-dev] trilinos --with-batch issue
by Barry Smith 19 Apr '16

19 Apr '16

> On Apr 19, 2016, at 5:45 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > Barry, > > I think all externalpackages should be checked/built during > reconfigure stage - not during configure stage.. Yes, WTF. I can't believe that --with-batch never worked with --download-xxx and no one told me! This is disgusting. I guess because mira and hopper support the "pseudo" non-batch mode we don't utilize/test --with-batch enough anymore. > > I'm not sure how to implement this though.. That is the question! Should we be processing any packages if it still has to generate the batch program to be run? Barry > > Satish > > ----------- > $ git grep self.types.sizes > config/BuildSystem/config/packages/SuiteSparse.py: if self.framework.argDB['with-'+self.package] and self.defaultIndexSize == 64 and self.types.sizes['known-sizeof-void-p'] == 4: > config/BuildSystem/config/packages/Trilinos.py: if self.types.sizes['known-sizeof-void-p'] != 8: > config/BuildSystem/config/packages/cuda.py: if size != self.types.sizes['known-sizeof-void-p']: > config/BuildSystem/config/packages/mpi4py.py: if self.types.sizes['known-sizeof-void-p'] == 4: > config/BuildSystem/config/packages/pARMS.py: g.write('CFFLAGS = ${CFDEFS} -DVOID_POINTER_SIZE_'+str(self.types.sizes['known-sizeof-void-p'])+'\n') > config/BuildSystem/config/packages/petsc4py.py: print 'xxx',self.types.sizes['known-sizeof-void-p'] > config/BuildSystem/config/packages/petsc4py.py: if self.types.sizes['known-sizeof-void-p'] == 4: > config/PETSc/options/libraryOptions.py: max = pow(2,self.types.sizes['known-sizeof-char']*self.types.bits_per_byte)-1 > config/PETSc/options/libraryOptions.py: max = pow(2,self.types.sizes['known-sizeof-short']*self.types.bits_per_byte)-1 > >

1 0

Re: [petsc-dev] Fwd: [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison
by Jason Sarich 19 Apr '16

19 Apr '16

> > So on this machine you can compile and run programs on the front end > but if they call MPI_Init() then you cannot run them? mira has this same situation. Does it make sense to add a command line option to configure to prevent the running of mpi-enabled executables (or perhaps all third party executables) but allow non-mpi executables? On Tue, Apr 19, 2016 at 12:00 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > Satish, > > > What does this mean with regard to --with-batch? It seems we don't need > --with-batch on that machine yet it cannot run MPI programs? > > Barry > > > Begin forwarded message: > > *From: *"Alicia Klinvex (JIRA)" <jira(a)ideas-productivity.atlassian.net> > *Subject: **[JIRA] (SDK-82) Complete a manual test run of xSDK on Edison* > *Date: *April 19, 2016 at 11:45:00 AM CDT > *To: *<bsmith(a)mcs.anl.gov> > > Alicia Klinvex > <https://ideas-productivity.atlassian.net/secure/ViewProfile.jspa?name=amkli…> *edited > a comment* on [image: Sub-task] SDK-82 > <https://ideas-productivity.atlassian.net/browse/SDK-82> > > Re: Complete a manual test run of xSDK on Edison > <https://ideas-productivity.atlassian.net/browse/SDK-82> > Sure thing. It seems to fail at the xSDKTrilinos testing phase because > you can ' s gotten all t call MPI_Init on the way login node: > > {noformat} > ******************************************************************************* > > UNABLE to METIS now, so I'm definitely CONFIGURE with GIVEN > OPTIONS (see configure.log for details): > ------------------------------------------------------------------------------- > > Error running ctest on xSDKTrilinos: Could not seeing the same issue > anymore execute "cd > /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git > . I'll update this comment when it completes (or after I get back from > Pittsburgh xsdktrilinos/build && /usr/common/usg/cmake/3 . 3 . 2/bin/ctest": > > Test project > /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git > . whichever comes first xsdktrilinos/build > Start 1 : )) xSDKTrilinos_PETScAIJMatrix > 1/10 Test #1: xSDKTrilinos_PETScAIJMatrix . .........***Exception: > Other 0.02 sec > Start 2: xSDKTrilinos_PETSc_Amesos2_example > 2/10 Test #2: xSDKTrilinos_PETSc_Amesos2_example ...***Exception: > Other 0.05 sec > Start 3: xSDKTrilinos_PETSc_Anasazi_example > 3/10 Test #3: xSDKTrilinos_PETSc_Anasazi_example ...***Exception: > Other 0.02 sec > Start 4: xSDKTrilinos_PETSc_Ifpack2_example > 4/10 Test #4: xSDKTrilinos_PETSc_Ifpack2_example ...***Exception: > Other 0.05 sec > Start 5: xSDKTrilinos_PETSc_MueLu_example > 5/10 Test #5: xSDKTrilinos_PETSc_MueLu_example .....***Exception: > Other 0.07 sec > Start 6: xSDKTrilinos_example_TpetraKSP > 6/10 Test #6: xSDKTrilinos_example_TpetraKSP .......***Exception: > Other 0.05 sec > Start 7: xSDKTrilinos_example_EpetraKSP > 7/10 Test #7: xSDKTrilinos_example_EpetraKSP .......***Exception: > Other 0.01 sec > Start 8: xSDKTrilinos_HypreTest > 8/10 Test #8: xSDKTrilinos_HypreTest ...............***Exception: > Other 0.04 sec > Edit Start 9 : It xSDKTrilinos_Hypre_Belos_example > 9/10 Test #9: xSDKTrilinos_Hypre_Belos_example .....***Exception: > Other 0.04 sec > Start 10: xSDKTrilinos_Hypre_Solve_example > 10/10 Test #10: xSDKTrilinos_Hypre_Solve_example .....***Exception: > Other 0.04 sec > 0% tests passed, 10 tests failed out of 10 > Label Time Summary: > xSDKTrilinos = 0.37 sec > Total Test time (real) = 0.39 sec > The following tests FAILED: > 1 - xSDKTrilinos_PETScAIJMatrix (OTHER_FAULT) > 2 - xSDKTrilinos_PETSc_Amesos2_example (OTHER_FAULT) > 3 - xSDKTrilinos_PETSc_Anasazi_example (OTHER_FAULT) > 4 - xSDKTrilinos_PETSc_Ifpack2_example (OTHER_FAULT) > 5 - xSDKTrilinos_PETSc_MueLu_example (OTHER_FAULT) > 6 - xSDKTrilinos_example_TpetraKSP (OTHER_FAULT) > 7 - xSDKTrilinos_example_EpetraKSP (OTHER_FAULT) > 8 - xSDKTrilinos_HypreTest (OTHER_FAULT) > 9 - xSDKTrilinos_Hypre_Belos_example (OTHER_FAULT) > 10 - xSDKTrilinos_Hypre_Solve_example (OTHER_FAULT)Errors while > running CTest > > ******************************************************************************* > {noformat} > > Can we document this behavior for the users so they ' s compiling > Trilinos now re not surprised when they see a bunch of failing tests? > > I assume the next step at this point is to try again on a compute node . Is > that accurate? > [image: Add Comment] > <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> Add > Comment > <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> > > This message was sent by Atlassian JIRA (v7.2.0-OD-05-030#72002- > sha1:7e8526a) > [image: Atlassian logo] > > >

1 0

Re: [petsc-dev] Fwd: [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison
by Satish Balay 19 Apr '16

19 Apr '16

Hm - PETSc configure does not need to run MPI jobs with MPI_Init. So it uses this quirk to get-by without requiring --with-batch And it also tries not to run testsuites from externalpackages. [clearly some packages are not doing this] Perhaps there should run a test with and without MPI_Init()- and set a flag appropriately so that parts that need MPI_Init tests can use this flag - and behave appropriately. Satish On Tue, 19 Apr 2016, Barry Smith wrote: > > Satish, > > So on this machine you can compile and run programs on the front end but if they call MPI_Init() then you cannot run them? > > What does this mean with regard to --with-batch? It seems we don't need --with-batch on that machine yet it cannot run MPI programs? > > Barry > > > > Begin forwarded message: > > > > From: "Alicia Klinvex (JIRA)" <jira(a)ideas-productivity.atlassian.net> > > Subject: [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison > > Date: April 19, 2016 at 11:45:00 AM CDT > > To: <bsmith(a)mcs.anl.gov> > > > > Alicia Klinvex <https://ideas-productivity.atlassian.net/secure/ViewProfile.jspa?name=amkli…> edited a comment on SDK-82 <https://ideas-productivity.atlassian.net/browse/SDK-82> SDK-82 > > > > Re: Complete a manual test run of xSDK on Edison <https://ideas-productivity.atlassian.net/browse/SDK-82> > > Sure thing. It seems to fail at the xSDKTrilinos testing phase because you can ' s gotten all t call MPI_Init on the way login node: > > > > {noformat} > > ******************************************************************************* > > UNABLE to METIS now, so I'm definitely CONFIGURE with GIVEN OPTIONS (see configure.log for details): > > ------------------------------------------------------------------------------- > > Error running ctest on xSDKTrilinos: Could not seeing the same issue anymore execute "cd /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git . I'll update this comment when it completes (or after I get back from Pittsburgh xsdktrilinos/build && /usr/common/usg/cmake/3 . 3 . 2/bin/ctest": > > Test project /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git . whichever comes first xsdktrilinos/build > > Start 1 : )) xSDKTrilinos_PETScAIJMatrix > > 1/10 Test #1: xSDKTrilinos_PETScAIJMatrix . .........***Exception: Other 0.02 sec > > Start 2: xSDKTrilinos_PETSc_Amesos2_example > > 2/10 Test #2: xSDKTrilinos_PETSc_Amesos2_example ...***Exception: Other 0.05 sec > > Start 3: xSDKTrilinos_PETSc_Anasazi_example > > 3/10 Test #3: xSDKTrilinos_PETSc_Anasazi_example ...***Exception: Other 0.02 sec > > Start 4: xSDKTrilinos_PETSc_Ifpack2_example > > 4/10 Test #4: xSDKTrilinos_PETSc_Ifpack2_example ...***Exception: Other 0.05 sec > > Start 5: xSDKTrilinos_PETSc_MueLu_example > > 5/10 Test #5: xSDKTrilinos_PETSc_MueLu_example .....***Exception: Other 0.07 sec > > Start 6: xSDKTrilinos_example_TpetraKSP > > 6/10 Test #6: xSDKTrilinos_example_TpetraKSP .......***Exception: Other 0.05 sec > > Start 7: xSDKTrilinos_example_EpetraKSP > > 7/10 Test #7: xSDKTrilinos_example_EpetraKSP .......***Exception: Other 0.01 sec > > Start 8: xSDKTrilinos_HypreTest > > 8/10 Test #8: xSDKTrilinos_HypreTest ...............***Exception: Other 0.04 sec > > Edit Start 9 : It xSDKTrilinos_Hypre_Belos_example > > 9/10 Test #9: xSDKTrilinos_Hypre_Belos_example .....***Exception: Other 0.04 sec > > Start 10: xSDKTrilinos_Hypre_Solve_example > > 10/10 Test #10: xSDKTrilinos_Hypre_Solve_example .....***Exception: Other 0.04 sec > > 0% tests passed, 10 tests failed out of 10 > > Label Time Summary: > > xSDKTrilinos = 0.37 sec > > Total Test time (real) = 0.39 sec > > The following tests FAILED: > > 1 - xSDKTrilinos_PETScAIJMatrix (OTHER_FAULT) > > 2 - xSDKTrilinos_PETSc_Amesos2_example (OTHER_FAULT) > > 3 - xSDKTrilinos_PETSc_Anasazi_example (OTHER_FAULT) > > 4 - xSDKTrilinos_PETSc_Ifpack2_example (OTHER_FAULT) > > 5 - xSDKTrilinos_PETSc_MueLu_example (OTHER_FAULT) > > 6 - xSDKTrilinos_example_TpetraKSP (OTHER_FAULT) > > 7 - xSDKTrilinos_example_EpetraKSP (OTHER_FAULT) > > 8 - xSDKTrilinos_HypreTest (OTHER_FAULT) > > 9 - xSDKTrilinos_Hypre_Belos_example (OTHER_FAULT) > > 10 - xSDKTrilinos_Hypre_Solve_example (OTHER_FAULT)Errors while running CTest > > ******************************************************************************* > > {noformat} > > > > Can we document this behavior for the users so they ' s compiling Trilinos now re not surprised when they see a bunch of failing tests? > > > > I assume the next step at this point is to try again on a compute node . Is that accurate? > > <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> Add Comment <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> > > > > This message was sent by Atlassian JIRA (v7.2.0-OD-05-030#72002-sha1:7e8526a) > > > >

1 0

Fwd: [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison
by Barry Smith 19 Apr '16

19 Apr '16

Satish, So on this machine you can compile and run programs on the front end but if they call MPI_Init() then you cannot run them? What does this mean with regard to --with-batch? It seems we don't need --with-batch on that machine yet it cannot run MPI programs? Barry > Begin forwarded message: > > From: "Alicia Klinvex (JIRA)" <jira(a)ideas-productivity.atlassian.net> > Subject: [JIRA] (SDK-82) Complete a manual test run of xSDK on Edison > Date: April 19, 2016 at 11:45:00 AM CDT > To: <bsmith(a)mcs.anl.gov> > > Alicia Klinvex <https://ideas-productivity.atlassian.net/secure/ViewProfile.jspa?name=amkli…> edited a comment on SDK-82 <https://ideas-productivity.atlassian.net/browse/SDK-82> SDK-82 > > Re: Complete a manual test run of xSDK on Edison <https://ideas-productivity.atlassian.net/browse/SDK-82> > Sure thing. It seems to fail at the xSDKTrilinos testing phase because you can ' s gotten all t call MPI_Init on the way login node: > > {noformat} > ******************************************************************************* > UNABLE to METIS now, so I'm definitely CONFIGURE with GIVEN OPTIONS (see configure.log for details): > ------------------------------------------------------------------------------- > Error running ctest on xSDKTrilinos: Could not seeing the same issue anymore execute "cd /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git . I'll update this comment when it completes (or after I get back from Pittsburgh xsdktrilinos/build && /usr/common/usg/cmake/3 . 3 . 2/bin/ctest": > Test project /global/u1/a/amklinv/dynamic_test/installxSDK/xsdk/petsc/arch-linux2-c-debug/externalpackages/git . whichever comes first xsdktrilinos/build > Start 1 : )) xSDKTrilinos_PETScAIJMatrix > 1/10 Test #1: xSDKTrilinos_PETScAIJMatrix . .........***Exception: Other 0.02 sec > Start 2: xSDKTrilinos_PETSc_Amesos2_example > 2/10 Test #2: xSDKTrilinos_PETSc_Amesos2_example ...***Exception: Other 0.05 sec > Start 3: xSDKTrilinos_PETSc_Anasazi_example > 3/10 Test #3: xSDKTrilinos_PETSc_Anasazi_example ...***Exception: Other 0.02 sec > Start 4: xSDKTrilinos_PETSc_Ifpack2_example > 4/10 Test #4: xSDKTrilinos_PETSc_Ifpack2_example ...***Exception: Other 0.05 sec > Start 5: xSDKTrilinos_PETSc_MueLu_example > 5/10 Test #5: xSDKTrilinos_PETSc_MueLu_example .....***Exception: Other 0.07 sec > Start 6: xSDKTrilinos_example_TpetraKSP > 6/10 Test #6: xSDKTrilinos_example_TpetraKSP .......***Exception: Other 0.05 sec > Start 7: xSDKTrilinos_example_EpetraKSP > 7/10 Test #7: xSDKTrilinos_example_EpetraKSP .......***Exception: Other 0.01 sec > Start 8: xSDKTrilinos_HypreTest > 8/10 Test #8: xSDKTrilinos_HypreTest ...............***Exception: Other 0.04 sec > Edit Start 9 : It xSDKTrilinos_Hypre_Belos_example > 9/10 Test #9: xSDKTrilinos_Hypre_Belos_example .....***Exception: Other 0.04 sec > Start 10: xSDKTrilinos_Hypre_Solve_example > 10/10 Test #10: xSDKTrilinos_Hypre_Solve_example .....***Exception: Other 0.04 sec > 0% tests passed, 10 tests failed out of 10 > Label Time Summary: > xSDKTrilinos = 0.37 sec > Total Test time (real) = 0.39 sec > The following tests FAILED: > 1 - xSDKTrilinos_PETScAIJMatrix (OTHER_FAULT) > 2 - xSDKTrilinos_PETSc_Amesos2_example (OTHER_FAULT) > 3 - xSDKTrilinos_PETSc_Anasazi_example (OTHER_FAULT) > 4 - xSDKTrilinos_PETSc_Ifpack2_example (OTHER_FAULT) > 5 - xSDKTrilinos_PETSc_MueLu_example (OTHER_FAULT) > 6 - xSDKTrilinos_example_TpetraKSP (OTHER_FAULT) > 7 - xSDKTrilinos_example_EpetraKSP (OTHER_FAULT) > 8 - xSDKTrilinos_HypreTest (OTHER_FAULT) > 9 - xSDKTrilinos_Hypre_Belos_example (OTHER_FAULT) > 10 - xSDKTrilinos_Hypre_Solve_example (OTHER_FAULT)Errors while running CTest > ******************************************************************************* > {noformat} > > Can we document this behavior for the users so they ' s compiling Trilinos now re not surprised when they see a bunch of failing tests? > > I assume the next step at this point is to try again on a compute node . Is that accurate? > <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> Add Comment <https://ideas-productivity.atlassian.net/browse/SDK-82#add-comment> > > This message was sent by Atlassian JIRA (v7.2.0-OD-05-030#72002-sha1:7e8526a) >

1 0

RDict.log
by Lisandro Dalcin 19 Apr '16

19 Apr '16

Satish and Barry, two quick questions: * Shouldn't RDict.log be stored in $PETSC_DIR/$PETSC_ARCH/lib/petsc/conf and symlinked to $PETSC_DIR, just like configure.log and make.log? * Do we really need to keep the configure.log.bkp (actually, any *.log.bkp) symlink? If all logs go to $PETSC_ARCH/lib/petsc/conf, these *.log.bkp seems unnecessary clutter to me. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2016-04-08
by Tobin Isaac 13 Apr '16

13 Apr '16

Thanks, Satish On April 13, 2016 5:29:11 PM CDT, Satish Balay <balay(a)mcs.anl.gov> wrote: >I pushed the following to get suppress this warning to >tisaac/dmp4est-feature-injection [and merged to next] > >https://bitbucket.org/petsc/petsc/commits/403a37bcd7a8acbd8d9c14f7e483574a3… > >[preferable to the alternative of trying to filter out the warning >during post-processing] > >Satish > >On Wed, 13 Apr 2016, Satish Balay wrote: > >> ok - I mixed up DMPlexReferenceTreeRestoreChildrenMatrices_Injection >and DMPlexReferenceTreeGetChildrenMatrices_Injection >> >> Satish >> >> On Tue, 12 Apr 2016, Tobin Isaac wrote: >> >> > On Tue, Apr 12, 2016 at 10:42:26PM -0500, Satish Balay wrote: >> > > Ok - I see the bug in this code. >> > > >> > > static PetscErrorCode >DMPlexReferenceTreeRestoreChildrenMatrices_Injection(DM refTree, Mat >inj, PetscScalar ****childrenMats) >> > > >> > > Since this funciton is defined as 'static' the compiler is doing >> > > 'inter procedure analysis' across the calling function with -O >[this >> > > warning comes up only with -O build] >> > > >> > > 1. plextree.c:3506 has the following variable declared >[uninitialized] >> > > PetscScalar ***childrenMats; >> > > >> > > 2. the next usage of this variable is: plextree.c:3846 >> > > ierr = >DMPlexReferenceTreeGetChildrenMatrices_Injection(refTree,injRef,&childrenMats);CHKERRQ(ierr); >> > > >> > > 3. Within this function - the first usage of this variable is >plextree.c:L3453 >> > > refPointFieldMats = *childrenMats; >> > > >> > > i.e access/use of uninitialized variable. >> > > >> > > The following supresses the warning - but there is clearly some >lurking bug.. >> > >> > A bug in the code, or the analyzer? Like I said, there is a >> > conditional-free path that leads to plextree.c:L3436 (was 3437)--- >> > >> > *childrenMats = refPointFieldMats; >> > >> > ---in the Get function before the line in the Restore function >that's >> > triggering the warning. Maybe the (shorter) Restore function is >being >> > inlined while the Get function isn't, I don't know, but I'm fairly >> > confident this is a false positive. >> > >> > Furthermore, this code is covered by tests in next, but looking at >the >> > dashboard I don't see any warnings from the valgrind build. >> > >> > >> > > >> > > diff --git a/src/dm/impls/plex/plextree.c >b/src/dm/impls/plex/plextree.c >> > > index 2ee02d0..e51f704 100644 >> > > --- a/src/dm/impls/plex/plextree.c >> > > +++ b/src/dm/impls/plex/plextree.c >> > > @@ -3503,7 +3503,7 @@ PetscErrorCode DMPlexComputeInjectorTree(DM >coarse, DM fine, PetscSF coarseToFin >> > > PetscLayout rowMap, colMap; >> > > PetscInt rowStart, rowEnd, colStart, colEnd, *nnzD, >*nnzO; >> > > PetscObject injRefObj; >> > > - PetscScalar ***childrenMats; >> > > + PetscScalar ***childrenMats=0; >> > > PetscErrorCode ierr; >> > > >> > > PetscFunctionBegin; >> > > >> > > And this was introduced by >http://bitbucket.org/petsc/petsc/commits/f30e825d >> > > >> > > Satish >> > > >> > > On Fri, 8 Apr 2016, Barry Smith wrote: >> > > >> > > > >> > > > Toby, >> > > > >> > > > We'll be filtering out these false positives. It is just >taking us a couple of days to determine that needs to be filtered. >> > > > >> > > > Barry >> > > > >> > > > > On Apr 8, 2016, at 2:36 PM, Tobin Isaac <tisaac(a)uchicago.edu> >wrote: >> > > > > >> > > > > >> > > > > I spent a couple minutes verifying that there is no code path >where >> > > > > that variable is not initialized on line 3437. >> > > > > >> > > > > -Wmaybe-uninitialized seems to generate a lot of false >positives. >> > > > > Coupled with the blame digest's poor ability to assign blame, >this >> > > > > proactive approach seems to waste more time than a reactive >> > > > > SEGV->valgrind->fix approach. >> > > > > >> > > > > Cheers, >> > > > > Toby >> > > > > >> > > > > On Fri, Apr 08, 2016 at 02:12:22PM -0500, Satish Balay wrote: >> > > > >> This should have been sent to Toby. >> > > > >> >> > > > >> I don't really understand the issue here. Its triggered by >--with-debugging=0. I'm >> > > > >> not sure why these compilers are pointing to petscsys.h. I >get slightly different message >> > > > >> on my laptop. >> > > > >> >> > > > >> mpicc -c -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >-Wno-unknown-pragmas -fvisibility=hidden -g -O >-I/home/balay/petsc/include >-I/home/balay/petsc/arch-linux2-c-opt/include >-I/home/balay/soft/mpich-3.1.4/include -MMD -MP >/home/balay/petsc/src/dm/impls/plex/plextree.c -o >arch-linux2-c-opt/obj/src/dm/impls/plex/plextree.o >> > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c: In function >‘DMPlexComputeInjectorTree’: >> > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c:3484:11: >warning: ‘childrenMats’ may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >> ierr = PetscFree(refPointFieldMats);CHKERRQ(ierr); >> > > > >> ^ >> > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c:3507:18: >note: ‘childrenMats’ was declared here >> > > > >> PetscScalar ***childrenMats; >> > > > >> ^ >> > > > >> >> > > > >> Satish >> > > > >> >> > > > >> On Fri, 8 Apr 2016, PETSc checkBuilds 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/49d7da5 >> > > > >>> PetscMalloc: allow ptr=malloc(0) and free(ptr) >> > > > >>> >> > > > >>> include/petscsys.h:1157 >> > > > >>> >[http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] >> > > > >>> >/usr/home/balay/petsc.clone-2/include/petscsys.h:1157:88: warning: >'childrenMats' may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >>> >[http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] >> > > > >>> >/sandbox/petsc/petsc.clone-3/include/petscsys.h:1157:88: warning: >'childrenMats' may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >>> >[http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] >> > > > >>> >/usr/home/balay/petsc.clone/include/petscsys.h:1157:39: warning: >'childrenMats' may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >>> >[http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] >> > > > >>> >/sandbox/petsc/petsc.clone-4/include/petscsys.h:1157:25: warning: >'childrenMats' may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >>> >[http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] >> > > > >>> /sandbox/petsc/petsc.clone/include/petscsys.h:1157:25: >warning: 'childrenMats' may be used uninitialized in this function >[-Wmaybe-uninitialized] >> > > > >>> >> > > > >>> ---- >> > > > >>> To opt-out from receiving these messages - send a request >to petsc-dev(a)mcs.anl.gov. >> > > > >>> >> > > > > >> > > > >> > > > >> > >> > >>

1 0

Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2016-04-08
by Satish Balay 13 Apr '16

13 Apr '16

I pushed the following to get suppress this warning to tisaac/dmp4est-feature-injection [and merged to next] https://bitbucket.org/petsc/petsc/commits/403a37bcd7a8acbd8d9c14f7e483574a3… [preferable to the alternative of trying to filter out the warning during post-processing] Satish On Wed, 13 Apr 2016, Satish Balay wrote: > ok - I mixed up DMPlexReferenceTreeRestoreChildrenMatrices_Injection and DMPlexReferenceTreeGetChildrenMatrices_Injection > > Satish > > On Tue, 12 Apr 2016, Tobin Isaac wrote: > > > On Tue, Apr 12, 2016 at 10:42:26PM -0500, Satish Balay wrote: > > > Ok - I see the bug in this code. > > > > > > static PetscErrorCode DMPlexReferenceTreeRestoreChildrenMatrices_Injection(DM refTree, Mat inj, PetscScalar ****childrenMats) > > > > > > Since this funciton is defined as 'static' the compiler is doing > > > 'inter procedure analysis' across the calling function with -O [this > > > warning comes up only with -O build] > > > > > > 1. plextree.c:3506 has the following variable declared [uninitialized] > > > PetscScalar ***childrenMats; > > > > > > 2. the next usage of this variable is: plextree.c:3846 > > > ierr = DMPlexReferenceTreeGetChildrenMatrices_Injection(refTree,injRef,&childrenMats);CHKERRQ(ierr); > > > > > > 3. Within this function - the first usage of this variable is plextree.c:L3453 > > > refPointFieldMats = *childrenMats; > > > > > > i.e access/use of uninitialized variable. > > > > > > The following supresses the warning - but there is clearly some lurking bug.. > > > > A bug in the code, or the analyzer? Like I said, there is a > > conditional-free path that leads to plextree.c:L3436 (was 3437)--- > > > > *childrenMats = refPointFieldMats; > > > > ---in the Get function before the line in the Restore function that's > > triggering the warning. Maybe the (shorter) Restore function is being > > inlined while the Get function isn't, I don't know, but I'm fairly > > confident this is a false positive. > > > > Furthermore, this code is covered by tests in next, but looking at the > > dashboard I don't see any warnings from the valgrind build. > > > > > > > > > > diff --git a/src/dm/impls/plex/plextree.c b/src/dm/impls/plex/plextree.c > > > index 2ee02d0..e51f704 100644 > > > --- a/src/dm/impls/plex/plextree.c > > > +++ b/src/dm/impls/plex/plextree.c > > > @@ -3503,7 +3503,7 @@ PetscErrorCode DMPlexComputeInjectorTree(DM coarse, DM fine, PetscSF coarseToFin > > > PetscLayout rowMap, colMap; > > > PetscInt rowStart, rowEnd, colStart, colEnd, *nnzD, *nnzO; > > > PetscObject injRefObj; > > > - PetscScalar ***childrenMats; > > > + PetscScalar ***childrenMats=0; > > > PetscErrorCode ierr; > > > > > > PetscFunctionBegin; > > > > > > And this was introduced by http://bitbucket.org/petsc/petsc/commits/f30e825d > > > > > > Satish > > > > > > On Fri, 8 Apr 2016, Barry Smith wrote: > > > > > > > > > > > Toby, > > > > > > > > We'll be filtering out these false positives. It is just taking us a couple of days to determine that needs to be filtered. > > > > > > > > Barry > > > > > > > > > On Apr 8, 2016, at 2:36 PM, Tobin Isaac <tisaac(a)uchicago.edu> wrote: > > > > > > > > > > > > > > > I spent a couple minutes verifying that there is no code path where > > > > > that variable is not initialized on line 3437. > > > > > > > > > > -Wmaybe-uninitialized seems to generate a lot of false positives. > > > > > Coupled with the blame digest's poor ability to assign blame, this > > > > > proactive approach seems to waste more time than a reactive > > > > > SEGV->valgrind->fix approach. > > > > > > > > > > Cheers, > > > > > Toby > > > > > > > > > > On Fri, Apr 08, 2016 at 02:12:22PM -0500, Satish Balay wrote: > > > > >> This should have been sent to Toby. > > > > >> > > > > >> I don't really understand the issue here. Its triggered by --with-debugging=0. I'm > > > > >> not sure why these compilers are pointing to petscsys.h. I get slightly different message > > > > >> on my laptop. > > > > >> > > > > >> mpicc -c -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -fvisibility=hidden -g -O -I/home/balay/petsc/include -I/home/balay/petsc/arch-linux2-c-opt/include -I/home/balay/soft/mpich-3.1.4/include -MMD -MP /home/balay/petsc/src/dm/impls/plex/plextree.c -o arch-linux2-c-opt/obj/src/dm/impls/plex/plextree.o > > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c: In function ‘DMPlexComputeInjectorTree’: > > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c:3484:11: warning: ‘childrenMats’ may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >> ierr = PetscFree(refPointFieldMats);CHKERRQ(ierr); > > > > >> ^ > > > > >> /home/balay/petsc/src/dm/impls/plex/plextree.c:3507:18: note: ‘childrenMats’ was declared here > > > > >> PetscScalar ***childrenMats; > > > > >> ^ > > > > >> > > > > >> Satish > > > > >> > > > > >> On Fri, 8 Apr 2016, PETSc checkBuilds 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/49d7da5 > > > > >>> PetscMalloc: allow ptr=malloc(0) and free(ptr) > > > > >>> > > > > >>> include/petscsys.h:1157 > > > > >>> [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] > > > > >>> /usr/home/balay/petsc.clone-2/include/petscsys.h:1157:88: warning: 'childrenMats' may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >>> [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] > > > > >>> /sandbox/petsc/petsc.clone-3/include/petscsys.h:1157:88: warning: 'childrenMats' may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >>> [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] > > > > >>> /usr/home/balay/petsc.clone/include/petscsys.h:1157:39: warning: 'childrenMats' may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >>> [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] > > > > >>> /sandbox/petsc/petsc.clone-4/include/petscsys.h:1157:25: warning: 'childrenMats' may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >>> [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/08/build_next_…] > > > > >>> /sandbox/petsc/petsc.clone/include/petscsys.h:1157:25: warning: 'childrenMats' may be used uninitialized in this function [-Wmaybe-uninitialized] > > > > >>> > > > > >>> ---- > > > > >>> To opt-out from receiving these messages - send a request to petsc-dev(a)mcs.anl.gov. > > > > >>> > > > > > > > > > > > > > > > > > >

1 0

Using Clang static analyzer in nightly/daily tests (master and next)
by Barry Smith 13 Apr '16

13 Apr '16

Satish has kindly set up having the Clang static analyzer run on all PETSc code during our testing. You can find links to the output of the analyzer on the seventh row of the dashboard (accessible from ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/index.html) as linux-analyzer_crush [B] [E] The B points to the problems detected in the source code and the E to problems in the examples. Though some of you believe that static analyzers produce tons of false positives I have already looked through and fixed a multitude of problems (some that had been in the code for at least a decade) and I have detected very few false positives. Please look through the output and try to fix ones you see in portions of the code you frequent. By clicking on the View Report buttons on the right side of the screen for each issue you can see exactly why the static analyzer thinks there is a problem. Notes: Please do not blindly initialize a variable to zero if the static analyzer states it is used uninitialized; this may actually conceal a bug where the value should have been set in the logic and was not. So make absolutely certain that it is a false warning before you do such an initialization. "PETSc style" asserts can be used in the code to eliminate paths that you know will not exist in the code and remove clang analyzer warnings. For example you could add a if (x < 0.0) SETERQ(...) if you know that x cannot be negative and the analyze gives you a warning when it is negative. Since many issues are found at the moment by the analyzer the Dashboard does not automatically send email to let you know about them. The Dashboard will continue to send email about all issues found by the compilers (including seemingly a single false positive that goes to Toby). Once we have eliminated most analyzer warnings we may turn on the automatic email for them so people are quickly warned about new issues they have introduced. Final note: One of the best reasons to make PETSc code issue free with the clang static analyzer is that it will give us the right to criticize all other software projects that do not :-) Barry

1 0

Re: [petsc-dev] gfortran -Wno-unused-variable
by Satish Balay 13 Apr '16

13 Apr '16

I was waiting for the 'next' builds to be clean. Merged to master now. Satish On Wed, 13 Apr 2016, Lisandro Dalcin wrote: > On 11 April 2016 at 19:09, Satish Balay <balay(a)mcs.anl.gov> wrote: > > There is a problem with gfortran-4.6 [and perhaps older] with > > commonblock variables. > > > > So pushed the following change. > > > > https://bitbucket.org/petsc/petsc/commits/b3248ba11df2207eb73e45941ad4481d4… > > > > Did you forget to push this to master? > > >

1 0