March 2020 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Request for comments: allow C99 internally
by Satish Balay 07 Mar '20

07 Mar '20

On Sat, 7 Mar 2020, Jed Brown wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > > On Fri, 6 Mar 2020, Jed Brown wrote: > >> PetscInt some,several,variables; > >> > >> // code > >> if (PetscDefined(HAVE_MAGIC)) { > >> function(several,&variables); > >> } > >> use(some,variables); > > > > One minor issue: we haven't yet fixed up clang analyzer build. Likely this will be listed as 'dead code' block or something like that. > > As with #ifdef, accurate code coverage needs to be aggregated across > multiple configurations. Are you aware of other problems? None that I can think off now.. Satish > > >> This approach could also be used to avoid needing separate macros for > >> every SETERRQ1-SETERRQ9, etc. I have an example implementation in this > >> MR, and it passes the full pipeline (after relaxing the -std=c89 > >> -pedantic build). > > > > These are in public includes. So apps using -std=c89 won't have access to this part of the API? > > Oh, I would keep the macros for a while (perhaps with gradual > deprecation starting eventually), just define the new ones for supported > dialects and use the new ones internally. >

1 0

Re: [petsc-dev] Request for comments: allow C99 internally
by Jed Brown 07 Mar '20

07 Mar '20

Satish Balay <balay(a)mcs.anl.gov> writes: >> +1 for the for-loop declarations. >> >> No more need to police the use of // C++-style comments? > > I think the objection was more about the code style. Mixing both types of comments does not look good. I don't have a problem with // for one-line comments and /* */ for multi-line. This would also be easy to batch replace across the whole (private) code base -- strictly /* */ in public headers. I'm also fine with keeping /* */ everywhere.

1 0

Re: [petsc-dev] Request for comments: allow C99 internally
by Jed Brown 07 Mar '20

07 Mar '20

Satish Balay <balay(a)mcs.anl.gov> writes: > On Fri, 6 Mar 2020, Jed Brown wrote: >> PetscInt some,several,variables; >> >> // code >> if (PetscDefined(HAVE_MAGIC)) { >> function(several,&variables); >> } >> use(some,variables); > > One minor issue: we haven't yet fixed up clang analyzer build. Likely this will be listed as 'dead code' block or something like that. As with #ifdef, accurate code coverage needs to be aggregated across multiple configurations. Are you aware of other problems? >> This approach could also be used to avoid needing separate macros for >> every SETERRQ1-SETERRQ9, etc. I have an example implementation in this >> MR, and it passes the full pipeline (after relaxing the -std=c89 >> -pedantic build). > > These are in public includes. So apps using -std=c89 won't have access to this part of the API? Oh, I would keep the macros for a while (perhaps with gradual deprecation starting eventually), just define the new ones for supported dialects and use the new ones internally.

1 0

Re: [petsc-dev] Request for comments: allow C99 internally
by Satish Balay 07 Mar '20

07 Mar '20

On Sat, 7 Mar 2020, Patrick Sanan wrote: > Perhaps naively, I‘d assume that while there may well be someone out there > relying on compilers for which this would be a problem, that same person is > also less likely to be able to upgrade PETSc. > > The benefits seem well worth it. It‘ll make things just that much easier to > work with. > > +1 for the for-loop declarations. > > No more need to police the use of // C++-style comments? I think the objection was more about the code style. Mixing both types of comments does not look good. Satish > > > > Jed Brown <jed(a)jedbrown.org> schrieb am Sa. 7. März 2020 um 06:48: > > > I have a question for petsc-dev: Do you know anyone who needs to build > > PETSc with a compiler that doesn't support variadic macros and for-loop > > declarations? (Both of these are in C99 and C++11, and supported by all > > tested configurations including compilers that don't fully implement > > these standards.) Both MPICH and Open MPI use variable-length arrays > > and for-loop declarations, so you'd be hard-pressed building a modern > > stack with such a compiler. I'm not proposing that we put these macros > > unguarded into the public headers, so a user of PETSc could still build > > with -std=c89 and the like. > > > > > > ## Background > > > > There is a common pattern in PETSc where we write > > > > PetscInt some,several,variables; > > > > // code > > #if defined(PETSC_HAVE_MAGIC) > > function(several,&variables); > > #endif > > use(some,variables); > > > > > > Of course this gives unused variable warnings, so we tear our code apart > > like > > > > PetscInt some,variables; > > #if defined(PETSC_HAVE_MAGIC) > > PetscInt several; > > #endif > > > > // code > > #if defined(PETSC_HAVE_MAGIC) > > function(several,&variables); > > #endif > > use(some,variables); > > > > > > but the bigger problem is that we need different configurations just to > > check syntax of our compiled out blocks. I propose allowing variadic > > macros (a C99 and C++11 feature) to allow code like > > > > PetscInt some,several,variables; > > > > // code > > if (PetscDefined(HAVE_MAGIC)) { > > function(several,&variables); > > } > > use(some,variables); > > > > > > This approach could also be used to avoid needing separate macros for > > every SETERRQ1-SETERRQ9, etc. I have an example implementation in this > > MR, and it passes the full pipeline (after relaxing the -std=c89 > > -pedantic build). > > > > https://gitlab.com/petsc/petsc/-/merge_requests/157/diffs > > > > > > We could also consider allowing for-loop declarations, which I believe > > leads to tighter and more understandable code because the reader doesn't > > have to wonder whether the variable is used after the loop. > > > > for (PetscInt i=0; i<n; i++) { ... } > > > > > > Note that we cannot use variable-length arrays (VLA) because they are > > not in the intersection of C and C++. > > >

1 0

Re: [petsc-dev] Request for comments: allow C99 internally
by Satish Balay 07 Mar '20

07 Mar '20

On Fri, 6 Mar 2020, Jed Brown wrote: > I have a question for petsc-dev: Do you know anyone who needs to build > PETSc with a compiler that doesn't support variadic macros and for-loop > declarations? (Both of these are in C99 and C++11, and supported by all > tested configurations including compilers that don't fully implement > these standards.) Both MPICH and Open MPI use variable-length arrays > and for-loop declarations, so you'd be hard-pressed building a modern > stack with such a compiler. I'm not proposing that we put these macros > unguarded into the public headers, so a user of PETSc could still build > with -std=c89 and the like. > > > ## Background > > There is a common pattern in PETSc where we write > > PetscInt some,several,variables; > > // code > #if defined(PETSC_HAVE_MAGIC) > function(several,&variables); > #endif > use(some,variables); > > > Of course this gives unused variable warnings, so we tear our code apart like > > PetscInt some,variables; > #if defined(PETSC_HAVE_MAGIC) > PetscInt several; > #endif > > // code > #if defined(PETSC_HAVE_MAGIC) > function(several,&variables); > #endif > use(some,variables); > > > but the bigger problem is that we need different configurations just to > check syntax of our compiled out blocks. I propose allowing variadic > macros (a C99 and C++11 feature) to allow code like > > PetscInt some,several,variables; > > // code > if (PetscDefined(HAVE_MAGIC)) { > function(several,&variables); > } > use(some,variables); One minor issue: we haven't yet fixed up clang analyzer build. Likely this will be listed as 'dead code' block or something like that. > > > This approach could also be used to avoid needing separate macros for > every SETERRQ1-SETERRQ9, etc. I have an example implementation in this > MR, and it passes the full pipeline (after relaxing the -std=c89 > -pedantic build). These are in public includes. So apps using -std=c89 won't have access to this part of the API? Satish > > https://gitlab.com/petsc/petsc/-/merge_requests/157/diffs > > > We could also consider allowing for-loop declarations, which I believe > leads to tighter and more understandable code because the reader doesn't > have to wonder whether the variable is used after the loop. > > for (PetscInt i=0; i<n; i++) { ... } > > > Note that we cannot use variable-length arrays (VLA) because they are > not in the intersection of C and C++. >

1 0

Re: [petsc-dev] Request for comments: allow C99 internally
by Patrick Sanan 07 Mar '20

07 Mar '20

Perhaps naively, I‘d assume that while there may well be someone out there relying on compilers for which this would be a problem, that same person is also less likely to be able to upgrade PETSc. The benefits seem well worth it. It‘ll make things just that much easier to work with. +1 for the for-loop declarations. No more need to police the use of // C++-style comments? Jed Brown <jed(a)jedbrown.org> schrieb am Sa. 7. März 2020 um 06:48: > I have a question for petsc-dev: Do you know anyone who needs to build > PETSc with a compiler that doesn't support variadic macros and for-loop > declarations? (Both of these are in C99 and C++11, and supported by all > tested configurations including compilers that don't fully implement > these standards.) Both MPICH and Open MPI use variable-length arrays > and for-loop declarations, so you'd be hard-pressed building a modern > stack with such a compiler. I'm not proposing that we put these macros > unguarded into the public headers, so a user of PETSc could still build > with -std=c89 and the like. > > > ## Background > > There is a common pattern in PETSc where we write > > PetscInt some,several,variables; > > // code > #if defined(PETSC_HAVE_MAGIC) > function(several,&variables); > #endif > use(some,variables); > > > Of course this gives unused variable warnings, so we tear our code apart > like > > PetscInt some,variables; > #if defined(PETSC_HAVE_MAGIC) > PetscInt several; > #endif > > // code > #if defined(PETSC_HAVE_MAGIC) > function(several,&variables); > #endif > use(some,variables); > > > but the bigger problem is that we need different configurations just to > check syntax of our compiled out blocks. I propose allowing variadic > macros (a C99 and C++11 feature) to allow code like > > PetscInt some,several,variables; > > // code > if (PetscDefined(HAVE_MAGIC)) { > function(several,&variables); > } > use(some,variables); > > > This approach could also be used to avoid needing separate macros for > every SETERRQ1-SETERRQ9, etc. I have an example implementation in this > MR, and it passes the full pipeline (after relaxing the -std=c89 > -pedantic build). > > https://gitlab.com/petsc/petsc/-/merge_requests/157/diffs > > > We could also consider allowing for-loop declarations, which I believe > leads to tighter and more understandable code because the reader doesn't > have to wonder whether the variable is used after the loop. > > for (PetscInt i=0; i<n; i++) { ... } > > > Note that we cannot use variable-length arrays (VLA) because they are > not in the intersection of C and C++. >

1 0

Request for comments: allow C99 internally
by Jed Brown 06 Mar '20

06 Mar '20

I have a question for petsc-dev: Do you know anyone who needs to build PETSc with a compiler that doesn't support variadic macros and for-loop declarations? (Both of these are in C99 and C++11, and supported by all tested configurations including compilers that don't fully implement these standards.) Both MPICH and Open MPI use variable-length arrays and for-loop declarations, so you'd be hard-pressed building a modern stack with such a compiler. I'm not proposing that we put these macros unguarded into the public headers, so a user of PETSc could still build with -std=c89 and the like. ## Background There is a common pattern in PETSc where we write PetscInt some,several,variables; // code #if defined(PETSC_HAVE_MAGIC) function(several,&variables); #endif use(some,variables); Of course this gives unused variable warnings, so we tear our code apart like PetscInt some,variables; #if defined(PETSC_HAVE_MAGIC) PetscInt several; #endif // code #if defined(PETSC_HAVE_MAGIC) function(several,&variables); #endif use(some,variables); but the bigger problem is that we need different configurations just to check syntax of our compiled out blocks. I propose allowing variadic macros (a C99 and C++11 feature) to allow code like PetscInt some,several,variables; // code if (PetscDefined(HAVE_MAGIC)) { function(several,&variables); } use(some,variables); This approach could also be used to avoid needing separate macros for every SETERRQ1-SETERRQ9, etc. I have an example implementation in this MR, and it passes the full pipeline (after relaxing the -std=c89 -pedantic build). https://gitlab.com/petsc/petsc/-/merge_requests/157/diffs We could also consider allowing for-loop declarations, which I believe leads to tighter and more understandable code because the reader doesn't have to wonder whether the variable is used after the loop. for (PetscInt i=0; i<n; i++) { ... } Note that we cannot use variable-length arrays (VLA) because they are not in the intersection of C and C++.

1 0

Signal handling
by Lisandro Dalcin 05 Mar '20

05 Mar '20

I've implemented some lightweight signal handling facilities. See the attached header and implementation files for a taste of the current API, and the pseudo-example code showing how to use it, briefly described below: Right now I'm using it to interact with the job scheduler during (explicit) timestepping. I have being/end signal handling calls around TSSolve(). A PostStep() routine catches signals and handles them this way: * If SIGINT or SIGTERM, I dump a restart file and set converged reason to USER to stop. * If SIGUSR1, I dump a restart file and continue timestepping. * if SIGUSR2, I dump a VTK file and continue timestepping. I can send signals to the job with `scancel -s SIG<NAME>`. When the job time allocation is about to expire, SLURM fist sends SIGTERM and waits some time before SIGKILL. That time is enough to get a restart file from the last step, stop timestepping and finalize gracefully. I'm not 100% happy with the API, maybe I should make it easier to use. For example, I could define each PETSC_SIGXXX so that I do need the macro PetscSigMask(). That would complicate a bit the mapping signal enum -> name string, though. I could also implement PetscSignalRaise(), it may be useful, but I'm not sure. Do you think this may be of some value for core PETSc? I'm asking before submitting a MR because that would require writing some docs, I don't want to do the doc work before knowing your opinion first :-). Regards, -- Lisandro Dalcin ============ Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

1 0

Fwd: [Xlab] El Capitan CPU announcement
by Smith, Barry F. 05 Mar '20

05 Mar '20

Begin forwarded message: From: "Thakur, Rajeev" <thakur(a)anl.gov<mailto:[email protected]>> Subject: [Xlab] El Capitan CPU announcement Date: March 4, 2020 at 1:33:13 PM CST To: "xlab(a)cels.anl.gov<mailto:[email protected]>" <xlab(a)cels.anl.gov<mailto:[email protected]>> AMD https://www.anandtech.com/show/15581/el-capitan-supercomputer-detailed-amd-… _______________________________________________ Xlab mailing list Xlab(a)lists.cels.anl.gov https://lists.cels.anl.gov/mailman/listinfo/xlab

1 0