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

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: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 Dmitry Karpeev 11 May '12

11 May '12

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? 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

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. 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] Any plan to release pipelihed GMRES??
by Jed Brown 11 May '12

11 May '12

On Fri, May 11, 2012 at 10:01 AM, Keita Teranishi <keita(a)cray.com> wrote: > I’d like to know if you have any plan to release Pipelined GMRES method, > recently published by Intel Research in Europe.**** > > If so, are you going to include it in the next release? > It is -ksp_type pgmres

1 0

Any plan to release pipelihed GMRES??
by Keita Teranishi 11 May '12

11 May '12

Hello, I'd like to know if you have any plan to release Pipelined GMRES method, recently published by Intel Research in Europe. If so, are you going to include it in the next release? Thank you, ==================================== Keita Teranishi Scientific Library Group Cray Inc. keita(a)cray.com ======================================

1 0

As if we need convincing
by Matthew Knepley 11 May '12

11 May '12

http://www.250bpm.com/blog:4 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] OpenMP Support
by Gerard Gorman 10 May '12

10 May '12

Hi Dave I should just say that we still have not finished a code review with the petsc-dev team so any faults should be assumed to be ours rather than theirs! Michele just put a preprint of our paper covering the preliminary work on arXiv, which you might found useful: http://arxiv.org/abs/1205.2005 As we have not yet merged with the truck so you'd need to pull a branch from: https://bitbucket.org/wence/petsc-dev-omp and configure using --with-openmp A key issue when running is to set thread/core affinity. Unfortunately there is no general way of doing this - it depends on your compiler. But likwid-pin can make your life a little easier: http://code.google.com/p/likwid/wiki/LikwidPin Cheers Gerard Dave Nystrom emailed the following on 10/05/12 05:55: > Hi Gerard, > > Thanks for the info. Is there any documentation on how to use the petsc > OpenMP support? I would be interested in trying it out. > > Thanks, > > Dave > > Gerard Gorman writes: > > Hi Dave > > > > OpenMP support exists for vec and mat (only AIJ so far). There is a big > > difference in performance depending on available memory bandwidth and > > the compiler OpenMP implementation. In application codes (such as > > Fluidity which is our main target code for this work) there are other > > significant costs such as matrix assembly. So in general you have to > > consider how easy it will be to thread to the other computationally > > expensive sections of your code, otherwise the overall speed-up of your > > application will be modest. > > > > Cheers > > Gerard > > > > Dave Nystrom emailed the following on 09/05/12 04:29: > > > Is the pthreads support further along than the OpenMP support? I have not > > > tried the pthreads support yet. Does either the pthreads support or the > > > OpenMP support implement the matvec or do they just do vector type > > > operations? > > > > > > Jed Brown writes: > > > > On Tue, May 8, 2012 at 9:23 PM, Dave Nystrom <dnystrom1(a)comcast.net> wrote: > > > > > > > > > I see that petsc-dev now has some OpenMP support. Would a serial, non-mpi > > > > > code that uses petsc-dev be able to gain much performance improvement from > > > > > it > > > > > now for the case of doing sparse linear solve with cg and jacobi > > > > > preconditioning? > > > > > > > > > > > > > The kernels are being transitioned to use the threadcomm, which enables > > > > OpenMP and other threading models. > > > > > > > > We anticipate that pthreads will provide the best performance because > > > > operations can be less synchronous than with OpenMP (for which a parallel > > > > region implies barrier semantics). But if other parts of an application > > > > are using OpenMP, it would be preferable for PETSc to also use OpenMP so > > > > that it can share the same thread pool. The same applies to TBB. > >

1 0

Re: [petsc-dev] Spelling Chebyshev
by Matthew Knepley 10 May '12

10 May '12

On Thu, May 10, 2012 at 4:27 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, May 10, 2012 at 3:23 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > >> It would seem to me that the best way to fix this is to just spell his >> name the way he did: Пафну́тий Льво́вич Чебышёв. All we need to do is >> update PETSc to use unicode strings. How hard could that be? >> > > Dmitry, can you translate the help strings and documentation to Russian > for the 3.3 release? Thanks. > I think Dmitry did this years ago, but it made typing options in too hard. 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] Spelling Chebyshev
by Jed Brown 10 May '12

10 May '12

On Thu, May 10, 2012 at 3:23 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > It would seem to me that the best way to fix this is to just spell his > name the way he did: Пафну́тий Льво́вич Чебышёв. All we need to do is > update PETSc to use unicode strings. How hard could that be? > Dmitry, can you translate the help strings and documentation to Russian for the 3.3 release? Thanks.

1 0

Re: [petsc-dev] Spelling Chebyshev
by Sean Farley 10 May '12

10 May '12

> I do not see Chebychev is being used. Good search ' Chebychev' fails as > well. Do you mean Google search? If so, it automatically changes the search to 'Chebyshev', click on 'Search instead for Chebychev'. There appear to be more spellings depending on your language (obviously): http://en.wikipedia.org/wiki/Pafnuty_Chebyshev It would seem to me that the best way to fix this is to just spell his name the way he did: Пафну́тий Льво́вич Чебышёв. All we need to do is update PETSc to use unicode strings. How hard could that be?

1 0