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

Re: [petsc-dev] Regression tests
by Gerard Gorman 29 Jul '12

29 Jul '12

Matthew Knepley emailed the following on 28/07/12 21:52: > On Sat, Jul 28, 2012 at 6:53 AM, Gerard Gorman > <g.gorman(a)imperial.ac.uk <mailto:[email protected]>> wrote: > > Slightly off topic - but I have Buildbot set up locally to keep an eye > on petsc-dev and various branches of petsc that I care about (if > you are > curious see http://stereolab.ese.ic.ac.uk:8080/waterfall - knock > yourself out with the force build button if you wish) > > Because this is a bot, 99% of time I only care about "pass", > "fail" ($? > != 0 is counted as a fail), "warning". For the testharness in our own > application code we just parse the output of unit tests for "pass", > "fail" and "warning" and list the tests that gave a warning or fail at > the end so a developer can take a closer look. I would like to do a > similar grepping for PETSc tests. Are the tests messages > standardised so > I can do this? At first glance I have: > > "pass" == "run successfully with" > "warning" == "Possible problem with" > "fail" == "mpiexec not found" or $? != 0 > > > I think you want > > http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/c11230be07bd/bin/maint/che… > > for builds, and what you have for tests. > > Matt > Thanks Gerard

1 0

Re: [petsc-dev] DMGetNamedGlobalVector() implementation?
by Matthew Knepley 29 Jul '12

29 Jul '12

On Sat, Jul 28, 2012 at 4:00 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 19, 2012 at 2:07 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> > I agree, but I could not find an easy way. >> >> Can you find a difficult way ? >> >> We chose to make the DM both a factory for creating stuff and a place >> to stash stuff that people can pull out later, this will lead to more and >> more of these loops. We could >> >> 1) do proper garbage collection always (yuck from the person who has to >> write that perspective) >> > > Due to the need for deterministic destruction in parallel, I think this > ends up more-or-less requiring eager loop-breaking, which means we have to > either (a) keep two-way links so that parents can have ref-count > information updated upon composition or (b) full dependency graph traversal > on each dereference. > > >> >> 2) have separate factories that the user manage; so basically split the >> DM into two parts that do not reference each other. (Yuck from the user >> perspective) >> >> 3) continue with all these hacks to prevent loops >> > > I think loops are only needed in special cases. We haven't needed them > until now. If we change DM to keep upward and downward links (nice for some > cases of FMG), those would also have the same concern. We could make a > PetscObjectComposeTwoWay() that created, and enforced two-way links. I'd > prefer not to allow arbitrary loops. > > >> >> 4) something else? > > > What about making PetscObjectDestroyChildren() explicit? Matt -- 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] DMGetNamedGlobalVector() implementation?
by Jed Brown 28 Jul '12

28 Jul '12

On Thu, Jul 19, 2012 at 2:07 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I agree, but I could not find an easy way. > > Can you find a difficult way ? > > We chose to make the DM both a factory for creating stuff and a place to > stash stuff that people can pull out later, this will lead to more and more > of these loops. We could > > 1) do proper garbage collection always (yuck from the person who has to > write that perspective) > Due to the need for deterministic destruction in parallel, I think this ends up more-or-less requiring eager loop-breaking, which means we have to either (a) keep two-way links so that parents can have ref-count information updated upon composition or (b) full dependency graph traversal on each dereference. > > 2) have separate factories that the user manage; so basically split the DM > into two parts that do not reference each other. (Yuck from the user > perspective) > > 3) continue with all these hacks to prevent loops > I think loops are only needed in special cases. We haven't needed them until now. If we change DM to keep upward and downward links (nice for some cases of FMG), those would also have the same concern. We could make a PetscObjectComposeTwoWay() that created, and enforced two-way links. I'd prefer not to allow arbitrary loops. > > 4) something else?

1 0

Re: [petsc-dev] Regression tests
by Matthew Knepley 28 Jul '12

28 Jul '12

On Sat, Jul 28, 2012 at 6:53 AM, Gerard Gorman <g.gorman(a)imperial.ac.uk>wrote: > Slightly off topic - but I have Buildbot set up locally to keep an eye > on petsc-dev and various branches of petsc that I care about (if you are > curious see http://stereolab.ese.ic.ac.uk:8080/waterfall - knock > yourself out with the force build button if you wish) > > Because this is a bot, 99% of time I only care about "pass", "fail" ($? > != 0 is counted as a fail), "warning". For the testharness in our own > application code we just parse the output of unit tests for "pass", > "fail" and "warning" and list the tests that gave a warning or fail at > the end so a developer can take a closer look. I would like to do a > similar grepping for PETSc tests. Are the tests messages standardised so > I can do this? At first glance I have: > > "pass" == "run successfully with" > "warning" == "Possible problem with" > "fail" == "mpiexec not found" or $? != 0 > I think you want http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/c11230be07bd/bin/maint/che… for builds, and what you have for tests. Matt Cheers > Gerard > > -- 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] Is there a reason for short arch and host names?
by Barry Smith 28 Jul '12

28 Jul '12

Thanks for pandering to my antediluvian ideas. Barry On Jul 28, 2012, at 11:37 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/93f374d090c4 > > On Fri, Jul 27, 2012 at 6:04 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I absolutely hate sizeof arch. That is one of the most perverse things people can do in C. What is wrong with good-old sizeof(arch)? > > Needs to go in the PETSc style guide :-) > > > Barry > > > On Jul 27, 2012, at 2:35 PM, Jed Brown wrote: > > > I'm sick of truncated PETSC_ARCH in log_summary. Does anyone object to my pushing the following to petsc-3.3? Should we just make all the fields huge so we're guaranteed to get everything? Since pname can be as long as PETSC_MAX_PATH_LEN, this is not a line we can reasonably limit/align. > > > > --- a/src/sys/plog/plog.c > > +++ b/src/sys/plog/plog.c > > @@ -1269,7 +1269,7 @@ > > PetscStageInfo *stageInfo = PETSC_NULL; > > PetscEventPerfInfo *eventInfo = PETSC_NULL; > > PetscClassPerfInfo *classInfo; > > - char arch[10], hostname[64], username[16], pname[PETSC_MAX_PATH_LEN], date[64]; > > + char arch[64], hostname[128], username[16], pname[PETSC_MAX_PATH_LEN], date[64]; > > const char *name; > > PetscLogDouble locTotalTime, TotalTime, TotalFlops; > > PetscLogDouble numMessages, messageLength, avgMessLen, numReductions; > > @@ -1311,12 +1311,12 @@ > > ierr = PetscFPrintf(comm, fd, "*** WIDEN YOUR WINDOW TO 120 CHARACTERS. Use 'enscript -r -fCourier9' to print this document ***\n");CHKERRQ(ierr); > > ierr = PetscFPrintf(comm, fd, "************************************************************************************************************************\n");CHKERRQ(ierr); > > ierr = PetscFPrintf(comm, fd, "\n---------------------------------------------- PETSc Performance Summary: ----------------------------------------------\n\n");CHKERRQ(ierr); > > - ierr = PetscGetArchType(arch, 10);CHKERRQ(ierr); > > - ierr = PetscGetHostName(hostname, 64);CHKERRQ(ierr); > > - ierr = PetscGetUserName(username, 16);CHKERRQ(ierr); > > + ierr = PetscGetArchType(arch,sizeof arch);CHKERRQ(ierr); > > + ierr = PetscGetHostName(hostname,sizeof hostname);CHKERRQ(ierr); > > + ierr = PetscGetUserName(username,sizeof username);CHKERRQ(ierr); > > ierr = PetscGetProgramName(pname, PETSC_MAX_PATH_LEN);CHKERRQ(ierr); > > - ierr = PetscGetDate(date, 64);CHKERRQ(ierr); > > - ierr = PetscGetVersion(version,256);CHKERRQ(ierr); > > + ierr = PetscGetDate(date,sizeof date);CHKERRQ(ierr); > > + ierr = PetscGetVersion(version,sizeof version);CHKERRQ(ierr); > > if (size == 1) { > > ierr = PetscFPrintf(comm,fd,"%s on a %s named %s with %d processor, by %s %s\n", pname, arch, hostname, size, username, date);CHKERRQ(ierr); > > } else { > > > >

1 0

Re: [petsc-dev] Is there a reason for short arch and host names?
by Jed Brown 28 Jul '12

28 Jul '12

http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/93f374d090c4 On Fri, Jul 27, 2012 at 6:04 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I absolutely hate sizeof arch. That is one of the most perverse > things people can do in C. What is wrong with good-old sizeof(arch)? > > Needs to go in the PETSc style guide :-) > > > Barry > > > On Jul 27, 2012, at 2:35 PM, Jed Brown wrote: > > > I'm sick of truncated PETSC_ARCH in log_summary. Does anyone object to > my pushing the following to petsc-3.3? Should we just make all the fields > huge so we're guaranteed to get everything? Since pname can be as long as > PETSC_MAX_PATH_LEN, this is not a line we can reasonably limit/align. > > > > --- a/src/sys/plog/plog.c > > +++ b/src/sys/plog/plog.c > > @@ -1269,7 +1269,7 @@ > > PetscStageInfo *stageInfo = PETSC_NULL; > > PetscEventPerfInfo *eventInfo = PETSC_NULL; > > PetscClassPerfInfo *classInfo; > > - char arch[10], hostname[64], username[16], > pname[PETSC_MAX_PATH_LEN], date[64]; > > + char arch[64], hostname[128], username[16], > pname[PETSC_MAX_PATH_LEN], date[64]; > > const char *name; > > PetscLogDouble locTotalTime, TotalTime, TotalFlops; > > PetscLogDouble numMessages, messageLength, avgMessLen, > numReductions; > > @@ -1311,12 +1311,12 @@ > > ierr = PetscFPrintf(comm, fd, "*** WIDEN YOUR WINDOW TO > 120 CHARACTERS. Use 'enscript -r -fCourier9' to print this document > ***\n");CHKERRQ(ierr); > > ierr = PetscFPrintf(comm, fd, > "************************************************************************************************************************\n");CHKERRQ(ierr); > > ierr = PetscFPrintf(comm, fd, > "\n---------------------------------------------- PETSc Performance > Summary: ----------------------------------------------\n\n");CHKERRQ(ierr); > > - ierr = PetscGetArchType(arch, 10);CHKERRQ(ierr); > > - ierr = PetscGetHostName(hostname, 64);CHKERRQ(ierr); > > - ierr = PetscGetUserName(username, 16);CHKERRQ(ierr); > > + ierr = PetscGetArchType(arch,sizeof arch);CHKERRQ(ierr); > > + ierr = PetscGetHostName(hostname,sizeof hostname);CHKERRQ(ierr); > > + ierr = PetscGetUserName(username,sizeof username);CHKERRQ(ierr); > > ierr = PetscGetProgramName(pname, PETSC_MAX_PATH_LEN);CHKERRQ(ierr); > > - ierr = PetscGetDate(date, 64);CHKERRQ(ierr); > > - ierr = PetscGetVersion(version,256);CHKERRQ(ierr); > > + ierr = PetscGetDate(date,sizeof date);CHKERRQ(ierr); > > + ierr = PetscGetVersion(version,sizeof version);CHKERRQ(ierr); > > if (size == 1) { > > ierr = PetscFPrintf(comm,fd,"%s on a %s named %s with %d processor, > by %s %s\n", pname, arch, hostname, size, username, date);CHKERRQ(ierr); > > } else { > > > >

1 0

Re: [petsc-dev] Regression tests
by Gerard Gorman 28 Jul '12

28 Jul '12

Slightly off topic - but I have Buildbot set up locally to keep an eye on petsc-dev and various branches of petsc that I care about (if you are curious see http://stereolab.ese.ic.ac.uk:8080/waterfall - knock yourself out with the force build button if you wish) Because this is a bot, 99% of time I only care about "pass", "fail" ($? != 0 is counted as a fail), "warning". For the testharness in our own application code we just parse the output of unit tests for "pass", "fail" and "warning" and list the tests that gave a warning or fail at the end so a developer can take a closer look. I would like to do a similar grepping for PETSc tests. Are the tests messages standardised so I can do this? At first glance I have: "pass" == "run successfully with" "warning" == "Possible problem with" "fail" == "mpiexec not found" or $? != 0 Cheers Gerard

1 0

Re: [petsc-dev] Is there a reason for short arch and host names?
by Jed Brown 27 Jul '12

27 Jul '12

As someone who believes in namespaces, it must be x = PetscAdditionScalar(a,b); On Jul 27, 2012 9:04 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > As someone who believes that abbreviations are the work of the devil I > would require x = Addition(a,b) > > Barry > > And since I don't believe in templates it would actually be x = > AdditionScalar(a,b) > > > On Jul 27, 2012, at 7:02 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > > > On Fri, Jul 27, 2012 at 6:20 PM, Jed Brown <five9a2(a)gmail.com> wrote: > >> By that logic, you should write +(a,b) instead of a+b. I'm looking > forward > >> to if (!(rank)) {...}. > > > > Not really, just for functions whose names are more than one-character > > long. Duh. > >

1 0

Re: [petsc-dev] Is there a reason for short arch and host names?
by Barry Smith 27 Jul '12

27 Jul '12

As someone who believes that abbreviations are the work of the devil I would require x = Addition(a,b) Barry And since I don't believe in templates it would actually be x = AdditionScalar(a,b) On Jul 27, 2012, at 7:02 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > On Fri, Jul 27, 2012 at 6:20 PM, Jed Brown <five9a2(a)gmail.com> wrote: >> By that logic, you should write +(a,b) instead of a+b. I'm looking forward >> to if (!(rank)) {...}. > > Not really, just for functions whose names are more than one-character > long. Duh.

1 0

Re: [petsc-dev] Is there a reason for short arch and host names?
by Barry Smith 27 Jul '12

27 Jul '12

I would be fine with a programing language that enforced that level of consistency. Barry On Jul 27, 2012, at 6:20 PM, Jed Brown <five9a2(a)gmail.com> wrote: > By that logic, you should write +(a,b) instead of a+b. I'm looking forward to if (!(rank)) {...}. > > On Jul 27, 2012 6:13 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > On Jul 27, 2012, at 6:08 PM, Jed Brown wrote: > > > (((MOAR) PARENTHESES)) > > > > One would think you were a Lisper. > > No because lisp puts the parenthesis in the wrong places. > > Actually I can handle only one concept: calling a function and I like the syntax to be the same for doing that all the time. > > Barry > > Just because it may be a pre-processor or compile time function and not a "real" runtime function doesn't make any different to me: I still need function(args). > > > > > On Jul 27, 2012 6:05 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > > > I absolutely hate sizeof arch. That is one of the most perverse things people can do in C. What is wrong with good-old sizeof(arch)? > > > > Needs to go in the PETSc style guide :-) > > > > > > Barry > > > > > > On Jul 27, 2012, at 2:35 PM, Jed Brown wrote: > > > > > I'm sick of truncated PETSC_ARCH in log_summary. Does anyone object to my pushing the following to petsc-3.3? Should we just make all the fields huge so we're guaranteed to get everything? Since pname can be as long as PETSC_MAX_PATH_LEN, this is not a line we can reasonably limit/align. > > > > > > --- a/src/sys/plog/plog.c > > > +++ b/src/sys/plog/plog.c > > > @@ -1269,7 +1269,7 @@ > > > PetscStageInfo *stageInfo = PETSC_NULL; > > > PetscEventPerfInfo *eventInfo = PETSC_NULL; > > > PetscClassPerfInfo *classInfo; > > > - char arch[10], hostname[64], username[16], pname[PETSC_MAX_PATH_LEN], date[64]; > > > + char arch[64], hostname[128], username[16], pname[PETSC_MAX_PATH_LEN], date[64]; > > > const char *name; > > > PetscLogDouble locTotalTime, TotalTime, TotalFlops; > > > PetscLogDouble numMessages, messageLength, avgMessLen, numReductions; > > > @@ -1311,12 +1311,12 @@ > > > ierr = PetscFPrintf(comm, fd, "*** WIDEN YOUR WINDOW TO 120 CHARACTERS. Use 'enscript -r -fCourier9' to print this document ***\n");CHKERRQ(ierr); > > > ierr = PetscFPrintf(comm, fd, "************************************************************************************************************************\n");CHKERRQ(ierr); > > > ierr = PetscFPrintf(comm, fd, "\n---------------------------------------------- PETSc Performance Summary: ----------------------------------------------\n\n");CHKERRQ(ierr); > > > - ierr = PetscGetArchType(arch, 10);CHKERRQ(ierr); > > > - ierr = PetscGetHostName(hostname, 64);CHKERRQ(ierr); > > > - ierr = PetscGetUserName(username, 16);CHKERRQ(ierr); > > > + ierr = PetscGetArchType(arch,sizeof arch);CHKERRQ(ierr); > > > + ierr = PetscGetHostName(hostname,sizeof hostname);CHKERRQ(ierr); > > > + ierr = PetscGetUserName(username,sizeof username);CHKERRQ(ierr); > > > ierr = PetscGetProgramName(pname, PETSC_MAX_PATH_LEN);CHKERRQ(ierr); > > > - ierr = PetscGetDate(date, 64);CHKERRQ(ierr); > > > - ierr = PetscGetVersion(version,256);CHKERRQ(ierr); > > > + ierr = PetscGetDate(date,sizeof date);CHKERRQ(ierr); > > > + ierr = PetscGetVersion(version,sizeof version);CHKERRQ(ierr); > > > if (size == 1) { > > > ierr = PetscFPrintf(comm,fd,"%s on a %s named %s with %d processor, by %s %s\n", pname, arch, hostname, size, username, date);CHKERRQ(ierr); > > > } else { > > > > > >

1 0