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

Re: [petsc-dev] making BuildSystem hard to debug
by Matthew Knepley 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 8:22 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > One thing that has always pissed me off about BuildSystem but for some > reason I never had the energy to bitch about is when a compile goes wrong, > BuildSystem logs the source code that wouldn't compiler BUT IT DOES NOT LOG > THE CONTENTS OF THE TWO FILES > > #include "confdefs.h" > #include "conffix.h" > > MAKING DEBUGGING HARDER. Can you please have BuildSystem log these files > when it logs the source code that didn't compiler. > We originally did this. It was way too long. I just debugged the same thing. Matt > Thanks > > > Barry > > > -- 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

making BuildSystem hard to debug
by Barry Smith 21 Mar '12

21 Mar '12

Matt, One thing that has always pissed me off about BuildSystem but for some reason I never had the energy to bitch about is when a compile goes wrong, BuildSystem logs the source code that wouldn't compiler BUT IT DOES NOT LOG THE CONTENTS OF THE TWO FILES #include "confdefs.h" #include "conffix.h" MAKING DEBUGGING HARDER. Can you please have BuildSystem log these files when it logs the source code that didn't compiler. Thanks Barry

1 0

Re: [petsc-dev] XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Matthew Knepley 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 7:16 AM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > or am I just blind? Where is this documented outside of the developer's > list? > It is perhaps not enough, but 3.2 Changes say that VecDestroy() now zeros the pointer so that it cannot be reused. Matt > A > -- 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

Re: [petsc-dev] --download-dependencies flag?
by Matthew Knepley 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 5:46 AM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > In order to get a user up-and-running with a MUMPs-enabled PETSc, I > followed this frustrating chain: > > configure --download-mumps=1 > > ... > > Error, no parmetis! > > configure --download-mumps=1 --download-parmetis=1 > > Error, no scalapack! > > configure --download-mumps=1 --download-parmetis=1 --download-scalapack=1 > > It would be convenient if the PETSc BuildSystem did what other package > installers like pip, yum, etc..., do, and grab dependencies that I need > based on what I have requested. > I don't like this at all. It works in yum because there is only one way to get the package. In PETSc, there are at least 3 since you can built it yourself, use the system version, or have it downloaded. Additionally, it would make it a lot easier to build PETSc on complicated > systems if BuildSystem did a quick dependency/flag check instead off the > way it works now (sequential intermixing of really slow and fast configure > options). > Yes, I agree it should alert people early that dependent packages are not turned on. Matt > A > -- 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

XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Aron Ahmadia 21 Mar '12

21 Mar '12

or am I just blind? Where is this documented outside of the developer's list? A

1 0

--download-dependencies flag?
by Aron Ahmadia 21 Mar '12

21 Mar '12

In order to get a user up-and-running with a MUMPs-enabled PETSc, I followed this frustrating chain: configure --download-mumps=1 ... Error, no parmetis! configure --download-mumps=1 --download-parmetis=1 Error, no scalapack! configure --download-mumps=1 --download-parmetis=1 --download-scalapack=1 It would be convenient if the PETSc BuildSystem did what other package installers like pip, yum, etc..., do, and grab dependencies that I need based on what I have requested. Additionally, it would make it a lot easier to build PETSc on complicated systems if BuildSystem did a quick dependency/flag check instead off the way it works now (sequential intermixing of really slow and fast configure options). A

1 0

Re: [petsc-dev] MPIX_Iallreduce()
by Jed Brown 20 Mar '12

20 Mar '12

On Tue, Mar 20, 2012 at 08:55, Satish Balay <balay(a)mcs.anl.gov> wrote: > are you pinning the mpi jobs to specific cores for this tests? Does it > make a difference? > It didn't seem to make a difference with 32 procs, but note that this example fits everything in cache. We should have a less contrived use case before putting more effort into it. With 64 procs, binding seems more important. jedbrown@cg:~/petsc/src/vec/vec/examples/tests$ ~/usr/mpich/bin/mpiexec -n 64 -binding rr ./ex42 -log_summary -splitreduction_async 0 | grep '^Vec' Vector Object: 64 MPI processes VecView 1 1.0 2.3429e-0387.0 0.00e+00 0.0 6.3e+01 4.0e+01 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecSet 1 1.0 2.1935e-05 7.7 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecAssemblyBegin 1 1.0 2.7320e-03 1.6 0.00e+00 0.0 0.0e+00 0.0e+00 3.0e+00 5 0 0 0 3 5 0 0 0 3 0 VecAssemblyEnd 1 1.0 3.0994e-0510.8 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecScatterBegin 300 1.0 7.4935e-04 1.4 0.00e+00 0.0 1.9e+04 4.0e+01 0.0e+00 1 0 98 99 0 1 0 98 99 0 0 VecScatterEnd 300 1.0 1.2340e-02 7.4 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 13 0 0 0 0 13 0 0 0 0 0 VecReduceArith 100 1.0 1.7476e-04 2.2 9.00e+02 1.0 0.0e+00 0.0e+00 0.0e+00 0100 0 0 0 0100 0 0 0 330 VecReduceComm 100 1.0 2.9184e-02 1.5 0.00e+00 0.0 0.0e+00 0.0e+00 1.0e+02 57 0 0 0 89 58 0 0 0 90 0 jedbrown@cg:~/petsc/src/vec/vec/examples/tests$ ~/usr/mpich/bin/mpiexec -n 64 -binding rr ./ex42 -log_summary -splitreduction_async 1 | grep '^Vec' Vector Object: 64 MPI processes VecView 1 1.0 1.7929e-0394.0 0.00e+00 0.0 6.3e+01 4.0e+01 0.0e+00 1 0 0 0 0 1 0 0 0 0 0 VecSet 1 1.0 2.6941e-05 5.7 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecAssemblyBegin 1 1.0 2.5909e-03 1.8 0.00e+00 0.0 0.0e+00 0.0e+00 3.0e+00 10 0 0 0 25 10 0 0 0 27 0 VecAssemblyEnd 1 1.0 2.4080e-05 4.8 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecScatterBegin 300 1.0 1.1673e-03 3.4 0.00e+00 0.0 1.9e+04 4.0e+01 0.0e+00 4 0 98 99 0 4 0 98 99 0 0 VecScatterEnd 300 1.0 2.0361e-03 3.3 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 7 0 0 0 0 7 0 0 0 0 0 VecReduceArith 100 1.0 2.0885e-04 2.9 9.00e+02 1.0 0.0e+00 0.0e+00 0.0e+00 1100 0 0 0 1100 0 0 0 276 VecReduceBegin 100 1.0 6.0058e-04 2.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 3 0 0 0 0 3 0 0 0 0 0 VecReduceEnd 100 1.0 2.7788e-03 1.8 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 13 0 0 0 0 13 0 0 0 0 0 > > I'm curious as this machine has assymetric cores wrt L2/FPU. > Presumably - using p0,p2,p4 etc should spread out the load - > but I don't know if the kernel is doing this automatically. >

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Jed Brown 20 Mar '12

20 Mar '12

On Tue, Mar 20, 2012 at 22:44, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Yes, I was terribly concerned (perhaps excessively) that the > src/docs/website not be undated before the tarball. Sean and Satish were > fine with that :-). Though in fairness until you brought it up I didn't > realize how stupid we had been for 15+ years without dates. I think the undated man pages are the most crucial. It's nice also get the rest of the docs. Using the extension instead of doing it manually prevents us from accidentally checking in changes when the update was run in-place.

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 10:38 PM, Jed Brown wrote: > On Tue, Mar 20, 2012 at 22:34, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > You will not be reading diffs of dates if the keyword extension works properly (i.e. like the RCS stuff works) > > Yup, I misinterpreted the extension. I would run one performance test before committing to it, but that looks like the way to go for src/docs. > > > Are we that concerned with src/docs/website being unnamed before writing the tarball? > > What does unnamed mean? > > I meant undated, but it sounds like the extension can do it transparently. Yes, I was terribly concerned (perhaps excessively) that the src/docs/website not be undated before the tarball. Sean and Satish were fine with that :-). Though in fairness until you brought it up I didn't realize how stupid we had been for 15+ years without dates. Barry

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Jed Brown 20 Mar '12

20 Mar '12

On Tue, Mar 20, 2012 at 22:34, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > You will not be reading diffs of dates if the keyword extension works > properly (i.e. like the RCS stuff works) > Yup, I misinterpreted the extension. I would run one performance test before committing to it, but that looks like the way to go for src/docs. > > Are we that concerned with src/docs/website being unnamed before writing > the tarball? > > What does unnamed mean? > I meant undated, but it sounds like the extension can do it transparently.

1 0