February 2017 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] I don't understand PETSCPARTITIONSHELL
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 9:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > So shell can 1) use some random partitioner or 2) allow the user to > provide the partitioning? > > This is a strange combination. Won't it be better to have > PETSCPARTIONERRANDOM and PETSCPARTITIONERSHELL? > > You could use the random for the tests (but as command line options not > hardwired in the examples). Oh God. Yes, I forgot that was in there. We can move it to Simple, where it makes sense. Matt > > Barry > > > > On Feb 9, 2017, at 9:45 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Thu, Feb 9, 2017 at 9:36 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > Matt, > > > > I don't understand PETSCPARTITIONSHELL. > > > > Why does it exist? Why not just use PETSCPARTITIONSIMPLE when no > other partitioner exists? > > > > Why is it called shell? Other XXSHELL allow users to provide their > own routines to provide the XX functionality, this does not seem to do > that. So it is not shell in the PETSc sense. > > > > Why hard wire examples to use it? Why not just have list it as an > args: in the test cases with -petscpartitioner_type shell (but why not just > simple?) putting the ugly shit directly into the source code seems > unnecessary and annoying. > > > > 1) The two partitioners do different things: > > > > Simple: It divides the cells evenly without reordering. > > > > Shell: It allows the user to set a prescribed partition > > > > It is clear to me that Shell is needed because sometimes you want to > prescribe the partition, if for no > > other reason than you know that a certain partition has a bug. Simple is > questionable, but we were > > using it for testing. > > > > 2) It is called Shell because for a shell the user prescribes the > behavior directly, which is exactly what happens. > > > > 3) I did not put it in arguments because it can get very long, and I > thought it was easier to see and manipulate in the code. I am open to > moving it. > > > > Matt > > > > > > > > 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 > > -- 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] I don't understand PETSCPARTITIONSHELL
by Barry Smith 09 Feb '17

09 Feb '17

So shell can 1) use some random partitioner or 2) allow the user to provide the partitioning? This is a strange combination. Won't it be better to have PETSCPARTIONERRANDOM and PETSCPARTITIONERSHELL? You could use the random for the tests (but as command line options not hardwired in the examples). Barry > On Feb 9, 2017, at 9:45 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 9:36 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > I don't understand PETSCPARTITIONSHELL. > > Why does it exist? Why not just use PETSCPARTITIONSIMPLE when no other partitioner exists? > > Why is it called shell? Other XXSHELL allow users to provide their own routines to provide the XX functionality, this does not seem to do that. So it is not shell in the PETSc sense. > > Why hard wire examples to use it? Why not just have list it as an args: in the test cases with -petscpartitioner_type shell (but why not just simple?) putting the ugly shit directly into the source code seems unnecessary and annoying. > > 1) The two partitioners do different things: > > Simple: It divides the cells evenly without reordering. > > Shell: It allows the user to set a prescribed partition > > It is clear to me that Shell is needed because sometimes you want to prescribe the partition, if for no > other reason than you know that a certain partition has a bug. Simple is questionable, but we were > using it for testing. > > 2) It is called Shell because for a shell the user prescribes the behavior directly, which is exactly what happens. > > 3) I did not put it in arguments because it can get very long, and I thought it was easier to see and manipulate in the code. I am open to moving it. > > Matt > > > > 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

Re: [petsc-dev] I don't understand PETSCPARTITIONSHELL
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 9:36 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > I don't understand PETSCPARTITIONSHELL. > > Why does it exist? Why not just use PETSCPARTITIONSIMPLE when no other > partitioner exists? > > Why is it called shell? Other XXSHELL allow users to provide their own > routines to provide the XX functionality, this does not seem to do that. So > it is not shell in the PETSc sense. > > Why hard wire examples to use it? Why not just have list it as an args: > in the test cases with -petscpartitioner_type shell (but why not just > simple?) putting the ugly shit directly into the source code seems > unnecessary and annoying. 1) The two partitioners do different things: Simple: It divides the cells evenly without reordering. Shell: It allows the user to set a prescribed partition It is clear to me that Shell is needed because sometimes you want to prescribe the partition, if for no other reason than you know that a certain partition has a bug. Simple is questionable, but we were using it for testing. 2) It is called Shell because for a shell the user prescribes the behavior directly, which is exactly what happens. 3) I did not put it in arguments because it can get very long, and I thought it was easier to see and manipulate in the code. I am open to moving it. Matt > > > 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

I don't understand PETSCPARTITIONSHELL
by Barry Smith 09 Feb '17

09 Feb '17

Matt, I don't understand PETSCPARTITIONSHELL. Why does it exist? Why not just use PETSCPARTITIONSIMPLE when no other partitioner exists? Why is it called shell? Other XXSHELL allow users to provide their own routines to provide the XX functionality, this does not seem to do that. So it is not shell in the PETSc sense. Why hard wire examples to use it? Why not just have list it as an args: in the test cases with -petscpartitioner_type shell (but why not just simple?) putting the ugly shit directly into the source code seems unnecessary and annoying. Barry

1 0

Re: [petsc-dev] every test example runs in a new directory with new test harness
by Barry Smith 09 Feb '17

09 Feb '17

The PETSc binary format is over 20 years old :-) Even if you want to change the format can't you just update the binary file that is diffed when you change the format? In the same way that when we change the format for -ksp_view ASCII we update the output files we diff against. It is not clear to me that having a test system that sequentializes test runs is simpler than a model that does not require sequentializing tests. Barry > On Feb 9, 2017, at 9:09 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 9:07 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > On Feb 9, 2017, at 7:26 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Thu, Feb 9, 2017 at 7:06 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: > > > So I need to check in this checkpoint file in order to test reading it in, > > > and also the diffing? I am not sure I like that better. > > > Shouldn't we design our test system to do this simple thing, rather than > > > clutter our repository for all time? > > > > Shouldn't we do the stronger test that guarantees the file format does > > not silently change? > > > > I don't think an undocumented format is as much of a consideration as keeping > > Why are you using an undocumented format? Doesn't seem such a good idea. > > We make these kinds of tradeoffs all the time. What is the overhead for documenting > something that may be changed soon. It is higher than we want to pay sometimes, > whereas testing something that exists pays off immediately. > > Matt > > > the repo clean. > > > > 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 > > > > > -- > 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] Fortran questions
by Barry Smith 09 Feb '17

09 Feb '17

> On Feb 9, 2017, at 8:49 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > 1) Has anyone else noticed a considerable increase in compile time due to the new Fortran code? No, the compile time is the same, it is the time to generate the module files that is much larger because 1) the module files are much larger because we do much more type checking (and I suspect that gfotran has nonscalable code in generating module files) and 2) gfortran does not use multiple threads to generate module files. Though the module generation time is a pain I blame it on gfortran and think it is a good tradeoff since we will get many viewer "bug reports" when people forget the ,ierr argument. > > 2) I have lost the ability to read Fortran arguments. I believe I have reconfigured, but will try again. Did this happen to anyone else? Do you mean command line arguments? I haven't seen this, send us details so we can reproduce. Barry > > 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] every test example runs in a new directory with new test harness
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 9:07 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > On Feb 9, 2017, at 7:26 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Thu, Feb 9, 2017 at 7:06 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: > > > So I need to check in this checkpoint file in order to test reading it > in, > > > and also the diffing? I am not sure I like that better. > > > Shouldn't we design our test system to do this simple thing, rather > than > > > clutter our repository for all time? > > > > Shouldn't we do the stronger test that guarantees the file format does > > not silently change? > > > > I don't think an undocumented format is as much of a consideration as > keeping > > Why are you using an undocumented format? Doesn't seem such a good idea. We make these kinds of tradeoffs all the time. What is the overhead for documenting something that may be changed soon. It is higher than we want to pay sometimes, whereas testing something that exists pays off immediately. Matt > > the repo clean. > > > > 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 > > -- 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] every test example runs in a new directory with new test harness
by Barry Smith 09 Feb '17

09 Feb '17

> On Feb 9, 2017, at 7:26 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Thu, Feb 9, 2017 at 7:06 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > > So I need to check in this checkpoint file in order to test reading it in, > > and also the diffing? I am not sure I like that better. > > Shouldn't we design our test system to do this simple thing, rather than > > clutter our repository for all time? > > Shouldn't we do the stronger test that guarantees the file format does > not silently change? > > I don't think an undocumented format is as much of a consideration as keeping Why are you using an undocumented format? Doesn't seem such a good idea. > the repo clean. > > 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

Fortran questions
by Matthew Knepley 09 Feb '17

09 Feb '17

1) Has anyone else noticed a considerable increase in compile time due to the new Fortran code? 2) I have lost the ability to read Fortran arguments. I believe I have reconfigured, but will try again. Did this happen to anyone else? 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] every test example runs in a new directory with new test harness
by Matthew Knepley 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 7:06 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > > So I need to check in this checkpoint file in order to test reading it > in, > > and also the diffing? I am not sure I like that better. > > Shouldn't we design our test system to do this simple thing, rather than > > clutter our repository for all time? > > Shouldn't we do the stronger test that guarantees the file format does > not silently change? > I don't think an undocumented format is as much of a consideration as keeping the repo clean. 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