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

Re: [petsc-dev] What needs to be done before a release?
by Sean Farley 11 May '12

11 May '12

On Fri, May 11, 2012 at 12:50 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Oh, yes we all do need that push! Yes, apparently so: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/5dbfbb5affa5 Hong, this is exactly what a code freeze is supposed to prevent (new features, instability, etc), and contributed code at that. Please wait to push these kind of changes until after 3.3 is released.

1 0

Re: [petsc-dev] API changes in MatIS
by Jed Brown 11 May '12

11 May '12

Isn't PtAP still the right operation, you just have a particular implementation that takes advantage of structure? I know you can also assemble B A^{-1} B^T, which is the same thing, and maybe we should provide a generic op for that. On May 11, 2012 1:17 PM, "Stefano Zampini" <stefano.zampini(a)gmail.com> wrote: > > 2012/5/11 Jed Brown <jedbrown(a)mcs.anl.gov> > >> I don't like this idea of the matrix type determining the algorithm, I'd >> rather choose the algorithm. >> > > This is note the case in my BDDC: it is the algorithm that drives the type > of matrix to be built. > > >> Can we decouple it by building the prolongation operator P whose columns >> are harmonic extension of the coarse nodes? Then the coarse operator looks >> like P^T A P just like multigrid (for which we have a matop) instead of >> looking like a Schur complement. >> > I already have it. Each process has its local part, splitted in the > matrices pcbddc->coarse_phi_B (local interface nodes) and (optionally) > pcbddc->coarse_phi_D (local dirichlet nodes). You can see that I used them > to check the correctness of the coarse local part in the code (see line > 1702 of bddc.c). I build the local part of coarse matrix , but I don't use > the expensive PtAP operation. Instead, I evaluate it by exploiting > properties of the saddle point problem they come from. > > > > >> On May 10, 2012 2:42 PM, "Stefano Zampini" <stefano.zampini(a)gmail.com> >> wrote: >> >>> >>> This is to do recursive BDDC or what? >>>> >>>> >>> Yes. When creating the BDDC coarse matrix, now the code has three 3 >>> options >>> >>> A) coarse matrix is a MATIS -> multilevel BDDC >>> B) coarse matrix is SEQAIJ -> one level BDDC with only one proc (or all) >>> solving directly the coarse problem >>> C) coarse matrix is MPIAIJ -> one level BDDC with a parallel direct >>> solve >>> >>> I think that PCREDUNDANT can do the job in both cases of options B if >>> the matrix would be parallel. >>> >> > > > -- > Stefano >

1 0

Re: [petsc-dev] API changes in MatIS
by Stefano Zampini 11 May '12

11 May '12

2012/5/11 Jed Brown <jedbrown(a)mcs.anl.gov> > I don't like this idea of the matrix type determining the algorithm, I'd > rather choose the algorithm. > This is note the case in my BDDC: it is the algorithm that drives the type of matrix to be built. > Can we decouple it by building the prolongation operator P whose columns > are harmonic extension of the coarse nodes? Then the coarse operator looks > like P^T A P just like multigrid (for which we have a matop) instead of > looking like a Schur complement. > I already have it. Each process has its local part, splitted in the matrices pcbddc->coarse_phi_B (local interface nodes) and (optionally) pcbddc->coarse_phi_D (local dirichlet nodes). You can see that I used them to check the correctness of the coarse local part in the code (see line 1702 of bddc.c). I build the local part of coarse matrix , but I don't use the expensive PtAP operation. Instead, I evaluate it by exploiting properties of the saddle point problem they come from. > On May 10, 2012 2:42 PM, "Stefano Zampini" <stefano.zampini(a)gmail.com> > wrote: > >> >> This is to do recursive BDDC or what? >>> >>> >> Yes. When creating the BDDC coarse matrix, now the code has three 3 >> options >> >> A) coarse matrix is a MATIS -> multilevel BDDC >> B) coarse matrix is SEQAIJ -> one level BDDC with only one proc (or all) >> solving directly the coarse problem >> C) coarse matrix is MPIAIJ -> one level BDDC with a parallel direct >> solve >> >> I think that PCREDUNDANT can do the job in both cases of options B if the >> matrix would be parallel. >> > -- Stefano

1 0

Re: [petsc-dev] API changes in MatIS
by Jed Brown 11 May '12

11 May '12

I don't like this idea of the matrix type determining the algorithm, I'd rather choose the algorithm. Can we decouple it by building the prolongation operator P whose columns are harmonic extension of the coarse nodes? Then the coarse operator looks like P^T A P just like multigrid (for which we have a matop) instead of looking like a Schur complement. On May 10, 2012 2:42 PM, "Stefano Zampini" <stefano.zampini(a)gmail.com> wrote: > > This is to do recursive BDDC or what? >> >> > Yes. When creating the BDDC coarse matrix, now the code has three 3 options > > A) coarse matrix is a MATIS -> multilevel BDDC > B) coarse matrix is SEQAIJ -> one level BDDC with only one proc (or all) > solving directly the coarse problem > C) coarse matrix is MPIAIJ -> one level BDDC with a parallel direct solve > > I think that PCREDUNDANT can do the job in both cases of options B if the > matrix would be parallel. >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Barry Smith 11 May '12

11 May '12

On May 11, 2012, at 12:22 PM, Satish Balay wrote: > On Fri, 11 May 2012, Barry Smith wrote: > >> >> On May 11, 2012, at 11:57 AM, Jed Brown wrote: >> >>> It'll necessarily be a branch after release. >> >> Yes, but as little of a branch as possible. >> >>> I thought we have branched at or near feature freeze in the past. >> >> I don't feel we are stable enough yet to make that branch. There is lots of shit that needs to be fixed and I don't want that shit represented both in the branch and the dev separatenly. I want the branch made only when we think the branch is pretty much done. > > making a release clone now is not a big deal [only issue is updating > the nightly builds with the correct clone] > > And Wrt commits - one would have to make sure appropriate ones go into > petsc-3.3 clone. And they will be pulled/merged into petsc-dev [and > there won't be any dulicate commits as would happen in svn-branches] > > The primary thing that avoiding a clone 'today' will acomplish is: > perhaps push everyone to concentrate more on release related > issues. But I guess most dont need this push. Oh, yes we all do need that push! Barry > > Satish > >> >> >> >>> Do you just not want to have to update your builds for a new clone? >> >> No, that is not the reason. >> >> Barry >> >>> >>> On May 11, 2012 11:54 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: >>> >>> On May 11, 2012, at 11:46 AM, Dmitry Karpeev wrote: >>> >>>> On Fri, May 11, 2012 at 11:40 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>>> >>>> Ok, in order to get the release out the door, please do not push development work to petsc-dev. Only push fixes and removal of dead code (DMMG for example). Also please run extensive tests and check the nightly builds. >>>> >>>> You can continue to do development; just continue to PULL into your development repository but don't PUSH to the master. To apply fixes to petsc-dev use another repository or one of "the cool guys" (Sean, Jed, and Matt's) way of only pushing up some changes. >>>> >>>> Questions? Send them. >>>> Why not set up a release repo and push fixes there, while continuing to push development changesets to petsc-dev? >>> >>> All the fixes that go in the "release repo" also need to go into the "development repo", I don't want to have any chance of the "release repo" becoming a branch; I want it to only be an earlier version of the development repo. >>> >>> Barry >>> >>> >>>> Dmitry. >>>> >>>> Thanks >>>> >>>> Barry >>>> >>>> >>>> Note: since the threaded code and gpu code continues to be in flux we will be continuing to support the use of those only in petsc-dev, not in the next petsc-release. >>>> >>>> >>>> On May 5, 2012, at 9:51 PM, Matthew Knepley wrote: >>>> >>>>> On Sat, May 5, 2012 at 10:32 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >>>>> On Fri, May 4, 2012 at 12:57 PM, Peter Brune <prbrune(a)gmail.com> wrote: >>>>> Jed, what else needs to be done with respect to getting all the SNES context into DM? I notice that, for instance, SNESSet/GetFunction is still mostly using the ops in SNES rather than the ones in SNESDM. >>>>> >>>>> I had a temporary option -snes_kspcompute to make the dispatch go through SNESDM. The main holdup now is -snes_grid_sequence, but I'm banging away at ex48 again, so I should be able to get it all working shortly. (I have ex48 running without DMMG, but some functionality is missing now, like changing the physics in the middle of the MG hierarchy.) >>>>> >>>>> Can we commit to a hard deadline? I would like the freeze for testing May 11, and clone and release May 14. >>>>> >>>>> 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] What needs to be done before a release?
by Satish Balay 11 May '12

11 May '12

On Fri, 11 May 2012, Barry Smith wrote: > > On May 11, 2012, at 11:57 AM, Jed Brown wrote: > > > It'll necessarily be a branch after release. > > Yes, but as little of a branch as possible. > > > I thought we have branched at or near feature freeze in the past. > > I don't feel we are stable enough yet to make that branch. There is lots of shit that needs to be fixed and I don't want that shit represented both in the branch and the dev separatenly. I want the branch made only when we think the branch is pretty much done. making a release clone now is not a big deal [only issue is updating the nightly builds with the correct clone] And Wrt commits - one would have to make sure appropriate ones go into petsc-3.3 clone. And they will be pulled/merged into petsc-dev [and there won't be any dulicate commits as would happen in svn-branches] The primary thing that avoiding a clone 'today' will acomplish is: perhaps push everyone to concentrate more on release related issues. But I guess most dont need this push. Satish > > > > > Do you just not want to have to update your builds for a new clone? > > No, that is not the reason. > > Barry > > > > > On May 11, 2012 11:54 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > > > On May 11, 2012, at 11:46 AM, Dmitry Karpeev wrote: > > > > > On Fri, May 11, 2012 at 11:40 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > Ok, in order to get the release out the door, please do not push development work to petsc-dev. Only push fixes and removal of dead code (DMMG for example). Also please run extensive tests and check the nightly builds. > > > > > > You can continue to do development; just continue to PULL into your development repository but don't PUSH to the master. To apply fixes to petsc-dev use another repository or one of "the cool guys" (Sean, Jed, and Matt's) way of only pushing up some changes. > > > > > > Questions? Send them. > > > Why not set up a release repo and push fixes there, while continuing to push development changesets to petsc-dev? > > > > All the fixes that go in the "release repo" also need to go into the "development repo", I don't want to have any chance of the "release repo" becoming a branch; I want it to only be an earlier version of the development repo. > > > > Barry > > > > > > > Dmitry. > > > > > > Thanks > > > > > > Barry > > > > > > > > > Note: since the threaded code and gpu code continues to be in flux we will be continuing to support the use of those only in petsc-dev, not in the next petsc-release. > > > > > > > > > On May 5, 2012, at 9:51 PM, Matthew Knepley wrote: > > > > > > > On Sat, May 5, 2012 at 10:32 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > On Fri, May 4, 2012 at 12:57 PM, Peter Brune <prbrune(a)gmail.com> wrote: > > > > Jed, what else needs to be done with respect to getting all the SNES context into DM? I notice that, for instance, SNESSet/GetFunction is still mostly using the ops in SNES rather than the ones in SNESDM. > > > > > > > > I had a temporary option -snes_kspcompute to make the dispatch go through SNESDM. The main holdup now is -snes_grid_sequence, but I'm banging away at ex48 again, so I should be able to get it all working shortly. (I have ex48 running without DMMG, but some functionality is missing now, like changing the physics in the middle of the MG hierarchy.) > > > > > > > > Can we commit to a hard deadline? I would like the freeze for testing May 11, and clone and release May 14. > > > > > > > > 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] What needs to be done before a release?
by Barry Smith 11 May '12

11 May '12

On May 11, 2012, at 11:57 AM, Jed Brown wrote: > It'll necessarily be a branch after release. Yes, but as little of a branch as possible. > I thought we have branched at or near feature freeze in the past. I don't feel we are stable enough yet to make that branch. There is lots of shit that needs to be fixed and I don't want that shit represented both in the branch and the dev separatenly. I want the branch made only when we think the branch is pretty much done. > Do you just not want to have to update your builds for a new clone? No, that is not the reason. Barry > > On May 11, 2012 11:54 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > On May 11, 2012, at 11:46 AM, Dmitry Karpeev wrote: > > > On Fri, May 11, 2012 at 11:40 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > Ok, in order to get the release out the door, please do not push development work to petsc-dev. Only push fixes and removal of dead code (DMMG for example). Also please run extensive tests and check the nightly builds. > > > > You can continue to do development; just continue to PULL into your development repository but don't PUSH to the master. To apply fixes to petsc-dev use another repository or one of "the cool guys" (Sean, Jed, and Matt's) way of only pushing up some changes. > > > > Questions? Send them. > > Why not set up a release repo and push fixes there, while continuing to push development changesets to petsc-dev? > > All the fixes that go in the "release repo" also need to go into the "development repo", I don't want to have any chance of the "release repo" becoming a branch; I want it to only be an earlier version of the development repo. > > Barry > > > > Dmitry. > > > > Thanks > > > > Barry > > > > > > Note: since the threaded code and gpu code continues to be in flux we will be continuing to support the use of those only in petsc-dev, not in the next petsc-release. > > > > > > On May 5, 2012, at 9:51 PM, Matthew Knepley wrote: > > > > > On Sat, May 5, 2012 at 10:32 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Fri, May 4, 2012 at 12:57 PM, Peter Brune <prbrune(a)gmail.com> wrote: > > > Jed, what else needs to be done with respect to getting all the SNES context into DM? I notice that, for instance, SNESSet/GetFunction is still mostly using the ops in SNES rather than the ones in SNESDM. > > > > > > I had a temporary option -snes_kspcompute to make the dispatch go through SNESDM. The main holdup now is -snes_grid_sequence, but I'm banging away at ex48 again, so I should be able to get it all working shortly. (I have ex48 running without DMMG, but some functionality is missing now, like changing the physics in the middle of the MG hierarchy.) > > > > > > Can we commit to a hard deadline? I would like the freeze for testing May 11, and clone and release May 14. > > > > > > 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] What needs to be done before a release?
by Sean Farley 11 May '12

11 May '12

> All the fixes that go in the "release repo" also need to go into the "development repo", I don't want to have any chance of the "release repo" becoming a branch; I want it to only be an earlier version of the development repo. Right ... which is why there is a "freeze" on the dev repo. Making a release implies that it will be a branch, see for instance: http://mercurial.selenic.com/wiki/StandardBranching Each of our petsc-3.X repos are open heads compared to petsc-dev. We could maintain the exact same workflow if we just had one petsc-dev repo with two branches: default (already there) and stable (an open head of the lastest release). Plus, we'd be able to use the 'graft' command to backport fixes.

1 0

Re: [petsc-dev] What needs to be done before a release?
by Sean Farley 11 May '12

11 May '12

> You can continue to do development; just continue to PULL into your development repository but don't PUSH to the master. To apply fixes to petsc-dev use another repository or one of "the cool guys" (Sean, Jed, and Matt's) way of only pushing up some changes. I use phases (introduced in 2.1) to mark changesets as 'secret' so they don't get pushed: http://mercurial.selenic.com/wiki/Phases I also use the color extension so that I can see the phase of each changeset, see my .hgrc for example: https://bitbucket.org/seanfarley/settings/src/1db1e00bd5b1/.hgrc

1 0

Re: [petsc-dev] What needs to be done before a release?
by Jed Brown 11 May '12

11 May '12

It'll necessarily be a branch after release. I thought we have branched at or near feature freeze in the past. Do you just not want to have to update your builds for a new clone? On May 11, 2012 11:54 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > On May 11, 2012, at 11:46 AM, Dmitry Karpeev wrote: > > > On Fri, May 11, 2012 at 11:40 AM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > Ok, in order to get the release out the door, please do not push > development work to petsc-dev. Only push fixes and removal of dead code > (DMMG for example). Also please run extensive tests and check the nightly > builds. > > > > You can continue to do development; just continue to PULL into your > development repository but don't PUSH to the master. To apply fixes to > petsc-dev use another repository or one of "the cool guys" (Sean, Jed, and > Matt's) way of only pushing up some changes. > > > > Questions? Send them. > > Why not set up a release repo and push fixes there, while continuing to > push development changesets to petsc-dev? > > All the fixes that go in the "release repo" also need to go into the > "development repo", I don't want to have any chance of the "release repo" > becoming a branch; I want it to only be an earlier version of the > development repo. > > Barry > > > > Dmitry. > > > > Thanks > > > > Barry > > > > > > Note: since the threaded code and gpu code continues to be in flux we > will be continuing to support the use of those only in petsc-dev, not in > the next petsc-release. > > > > > > On May 5, 2012, at 9:51 PM, Matthew Knepley wrote: > > > > > On Sat, May 5, 2012 at 10:32 PM, Jed Brown <jedbrown(a)mcs.anl.gov> > wrote: > > > On Fri, May 4, 2012 at 12:57 PM, Peter Brune <prbrune(a)gmail.com> > wrote: > > > Jed, what else needs to be done with respect to getting all the SNES > context into DM? I notice that, for instance, SNESSet/GetFunction is still > mostly using the ops in SNES rather than the ones in SNESDM. > > > > > > I had a temporary option -snes_kspcompute to make the dispatch go > through SNESDM. The main holdup now is -snes_grid_sequence, but I'm banging > away at ex48 again, so I should be able to get it all working shortly. (I > have ex48 running without DMMG, but some functionality is missing now, like > changing the physics in the middle of the MG hierarchy.) > > > > > > Can we commit to a hard deadline? I would like the freeze for testing > May 11, and clone and release May 14. > > > > > > 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