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

Re: [petsc-dev] Need mechanism to set LocalToGlobal mapping in a DMShell
by Dmitry Karpeev 21 Feb '13

21 Feb '13

On Thu, Feb 21, 2013 at 12:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu>wrote: > Hi Jed, > > The reason is that in the PFLOTRAN code we currently have some code like > this: > > select case(discretization%itype) > case(STRUCTURED_GRID,STRUCTURED_GRID_MIMETIC) > call > DMLocalToGlobalBegin(dm_ptr%sgdm,local_vec,INSERT_VALUES,global_vec,ierr) > call > DMLocalToGlobalEnd(dm_ptr%sgdm,local_vec,INSERT_VALUES,global_vec,ierr) > case(UNSTRUCTURED_GRID) > call VecScatterBegin(dm_ptr%ugdm%scatter_ltog,local_vec,global_vec, & > INSERT_VALUES,SCATTER_FORWARD,ierr) > call VecScatterEnd(dm_ptr%ugdm%scatter_ltog,local_vec,global_vec, & > INSERT_VALUES,SCATTER_FORWARD,ierr) > end select > > where in the STRUCTURED_GRID case we have a DMDA. In the > UNSTRUCTURED_GRID case we have no DM, and I want to pack things into a > DMShell so that have a DM and the various DM calls work (and then I can > eliminate these 'select case' statements). > > (Eventually I'd like to be using more of the PETSc infrastructure and not > even calling DMLocalToGlobalBegin(), etc., in the PFLOTRAN code, but that > can wait a bit.) > I would vote for DMGetLocalToGlobalMapping() etc. That has the flexibility to be used with DM-impl-oblivious codes. Dmitry. > > > --Richard > > > > On 2/21/13 1:42 PM, Jed Brown wrote: > > It would be natural to have a matching interface, but why do you need it? > You're in charge of making the matrices and vectors so you can give them > local-to-global mappings. The only solver that calls > DMGetLocalToGlobalMapping is PCEXOTIC, which only works with DMDA anyway. > > > On Thu, Feb 21, 2013 at 12:35 PM, Richard Tran Mills <rtm(a)eecs.utk.edu>wrote: > >> Hi Folks, >> >> I want to set a LocalToGlobal mapping in a DMShell object. Should we add >> a DMShell routine to do this, or just add a DMSetLocalToGlobalMapping() >> routine? >> >> Thanks, >> Richard >> >> -- >> Richard Tran Mills, Ph.D. >> Computational Earth Scientist | Joint Assistant Professor >> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >> Oak Ridge National Laboratory | University of Tennessee, Knoxville >> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >> >> > > > -- > Richard Tran Mills, Ph.D. > Computational Earth Scientist | Joint Assistant Professor > Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences > Oak Ridge National Laboratory | University of Tennessee, Knoxville > E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills > >

1 0

Re: [petsc-dev] Need mechanism to set LocalToGlobal mapping in a DMShell
by Richard Tran Mills 21 Feb '13

21 Feb '13

Hi Jed, The reason is that in the PFLOTRAN code we currently have some code like this: > select case(discretization%itype) > case(STRUCTURED_GRID,STRUCTURED_GRID_MIMETIC) > call > DMLocalToGlobalBegin(dm_ptr%sgdm,local_vec,INSERT_VALUES,global_vec,ierr) > call > DMLocalToGlobalEnd(dm_ptr%sgdm,local_vec,INSERT_VALUES,global_vec,ierr) > case(UNSTRUCTURED_GRID) > call > VecScatterBegin(dm_ptr%ugdm%scatter_ltog,local_vec,global_vec, & > INSERT_VALUES,SCATTER_FORWARD,ierr) > call VecScatterEnd(dm_ptr%ugdm%scatter_ltog,local_vec,global_vec, & > INSERT_VALUES,SCATTER_FORWARD,ierr) > end select where in the STRUCTURED_GRID case we have a DMDA. In the UNSTRUCTURED_GRID case we have no DM, and I want to pack things into a DMShell so that have a DM and the various DM calls work (and then I can eliminate these 'select case' statements). (Eventually I'd like to be using more of the PETSc infrastructure and not even calling DMLocalToGlobalBegin(), etc., in the PFLOTRAN code, but that can wait a bit.) --Richard On 2/21/13 1:42 PM, Jed Brown wrote: > It would be natural to have a matching interface, but why do you need > it? You're in charge of making the matrices and vectors so you can > give them local-to-global mappings. The only solver that calls > DMGetLocalToGlobalMapping is PCEXOTIC, which only works with DMDA anyway. > > > On Thu, Feb 21, 2013 at 12:35 PM, Richard Tran Mills <rtm(a)eecs.utk.edu > <mailto:[email protected]>> wrote: > > Hi Folks, > > I want to set a LocalToGlobal mapping in a DMShell object. Should > we add a DMShell routine to do this, or just add a > DMSetLocalToGlobalMapping() routine? > > Thanks, > Richard > > -- > Richard Tran Mills, Ph.D. > Computational Earth Scientist | Joint Assistant Professor > Hydrogeochemical Dynamics Team | EECS and Earth & Planetary > Sciences > Oak Ridge National Laboratory | University of Tennessee, > Knoxville > E-mail: rmills(a)ornl.gov <mailto:[email protected]> V: 865-241-3198 > <tel:865-241-3198> http://climate.ornl.gov/~rmills > <http://climate.ornl.gov/%7Ermills> > > -- Richard Tran Mills, Ph.D. Computational Earth Scientist | Joint Assistant Professor Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences Oak Ridge National Laboratory | University of Tennessee, Knoxville E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills

1 0

Re: [petsc-dev] Need mechanism to set LocalToGlobal mapping in a DMShell
by Peter Brune 21 Feb '13

21 Feb '13

Jed, I disagree; It's quite natural to want custom bindings for these things if you want some new mesh type to have local-to-global and global-to-local operations over that mesh. Having it abstracted out to the matrix or vector is constraining. They should totally be in there and should be implementation-level in DMShell. - Peter On Thu, Feb 21, 2013 at 12:42 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > It would be natural to have a matching interface, but why do you need it? > You're in charge of making the matrices and vectors so you can give them > local-to-global mappings. The only solver that calls > DMGetLocalToGlobalMapping is PCEXOTIC, which only works with DMDA anyway. > > > On Thu, Feb 21, 2013 at 12:35 PM, Richard Tran Mills <rtm(a)eecs.utk.edu>wrote: > >> Hi Folks, >> >> I want to set a LocalToGlobal mapping in a DMShell object. Should we add >> a DMShell routine to do this, or just add a DMSetLocalToGlobalMapping() >> routine? >> >> Thanks, >> Richard >> >> -- >> Richard Tran Mills, Ph.D. >> Computational Earth Scientist | Joint Assistant Professor >> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >> Oak Ridge National Laboratory | University of Tennessee, Knoxville >> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~** >> rmills <http://climate.ornl.gov/~rmills> >> >> >

1 0

Re: [petsc-dev] Need mechanism to set LocalToGlobal mapping in a DMShell
by Jed Brown 21 Feb '13

21 Feb '13

It would be natural to have a matching interface, but why do you need it? You're in charge of making the matrices and vectors so you can give them local-to-global mappings. The only solver that calls DMGetLocalToGlobalMapping is PCEXOTIC, which only works with DMDA anyway. On Thu, Feb 21, 2013 at 12:35 PM, Richard Tran Mills <rtm(a)eecs.utk.edu>wrote: > Hi Folks, > > I want to set a LocalToGlobal mapping in a DMShell object. Should we add > a DMShell routine to do this, or just add a DMSetLocalToGlobalMapping() > routine? > > Thanks, > Richard > > -- > Richard Tran Mills, Ph.D. > Computational Earth Scientist | Joint Assistant Professor > Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences > Oak Ridge National Laboratory | University of Tennessee, Knoxville > E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~**rmills<http://climate.ornl.gov/~rmills> > >

1 0

Need mechanism to set LocalToGlobal mapping in a DMShell
by Richard Tran Mills 21 Feb '13

21 Feb '13

Hi Folks, I want to set a LocalToGlobal mapping in a DMShell object. Should we add a DMShell routine to do this, or just add a DMSetLocalToGlobalMapping() routine? Thanks, Richard -- Richard Tran Mills, Ph.D. Computational Earth Scientist | Joint Assistant Professor Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences Oak Ridge National Laboratory | University of Tennessee, Knoxville E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills

1 0

Re: [petsc-dev] [SIAM-SC] DOE Workshop on Applied Mathematics Research for Exascale Computing
by Barry Smith 21 Feb '13

21 Feb '13

On Feb 21, 2013, at 7:00 AM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hi guys, > > it might be interesting to write a position paper from PETSc's point of view. It's just that I'm afraid that nobody will actually care about the issues of solving really interesting problems… You are correct, no one involved in this will care. Barry > > Best regards, > Karli > > > -------- Original Message -------- > Subject: [SIAM-SC] DOE Workshop on Applied Mathematics Research for Exascale Computing > Date: Wed, 20 Feb 2013 20:14:15 -0500 > From: Jack Dongarra <dongarra(a)eecs.utk.edu> > To: <siam-sc(a)siam.org> > > At the request of Advanced Scientific Computing Research (ASCR), Office of Science, US Department of Energy (DOE), the Exascale Mathematics Working Group (EMWG) is working to identify promising applied mathematics research opportunities that address the challenges of exascale computing. As part of the process, the EMWG is soliciting community input in the form of position papers. The EMWG will review these position papers and, based on the quality of their position papers, selected contributors may have the opportunity to participate in the Workshop on Applied Mathematics Research for Exascale Computing, currently planned for August 21-22, 2013 in Washington, D.C. > > Details of the position paper solicitation can be found at https://collab.mcs.anl.gov/display/examath/Call+for+Papers. > Position papers will be accepted until April 30, 2013. > Questions about the workshop can be sent to emwg.doe(a)gmail.com. > > ********************************************************** > Jack Dongarra; ORNL/UTK > http://www.cs.utk.edu/~dongarra/ > > > > > _______________________________________________ > SIAM-SC mailing list > To post messages to the list please send them to: SIAM-SC(a)siam.org > http://lists.siam.org/mailman/listinfo/siam-sc > >

1 0

Fwd: [SIAM-SC] DOE Workshop on Applied Mathematics Research for Exascale Computing
by Karl Rupp 21 Feb '13

21 Feb '13

Hi guys, it might be interesting to write a position paper from PETSc's point of view. It's just that I'm afraid that nobody will actually care about the issues of solving really interesting problems... Best regards, Karli -------- Original Message -------- Subject: [SIAM-SC] DOE Workshop on Applied Mathematics Research for Exascale Computing Date: Wed, 20 Feb 2013 20:14:15 -0500 From: Jack Dongarra <dongarra(a)eecs.utk.edu> To: <siam-sc(a)siam.org> At the request of Advanced Scientific Computing Research (ASCR), Office of Science, US Department of Energy (DOE), the Exascale Mathematics Working Group (EMWG) is working to identify promising applied mathematics research opportunities that address the challenges of exascale computing. As part of the process, the EMWG is soliciting community input in the form of position papers. The EMWG will review these position papers and, based on the quality of their position papers, selected contributors may have the opportunity to participate in the Workshop on Applied Mathematics Research for Exascale Computing, currently planned for August 21-22, 2013 in Washington, D.C. Details of the position paper solicitation can be found at https://collab.mcs.anl.gov/display/examath/Call+for+Papers. Position papers will be accepted until April 30, 2013. Questions about the workshop can be sent to emwg.doe(a)gmail.com. ********************************************************** Jack Dongarra; ORNL/UTK http://www.cs.utk.edu/~dongarra/ _______________________________________________ SIAM-SC mailing list To post messages to the list please send them to: SIAM-SC(a)siam.org http://lists.siam.org/mailman/listinfo/siam-sc

1 0

Re: [petsc-dev] concurrencykit
by Jed Brown 19 Feb '13

19 Feb '13

On Tue, Feb 19, 2013 at 4:01 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > What is your opinion of the longevity of support? Will we end up > supporting this library? Samy, the main developer, seems committed to supporting it, and has technical investment from his day job at AppNexus. I've conversed with him a few times and he seems capable. It has had a handful of external contributors, including a rackspace and linode address. It may not have big investment now, but I think it's the most viable thing out there right now and certainly has some industrial users.

1 0

Re: [petsc-dev] concurrencykit
by Barry Smith 19 Feb '13

19 Feb '13

On Feb 19, 2013, at 4:01 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Feb 19, 2013 at 4:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 19, 2013, at 3:43 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > I've started adding support for using this library for memory primitives and some basic lock-free data structures. > > > > http://concurrencykit.org/ > > > > Of course when threads are not used, we need some replacement. All the memory barriers and assignments become trivial and locks disappear so the no-threading variant is trivial to implement. My question now is whether to call ck_* functions directly from PETSc source or to always wrap them in Petsc* namespaced macros and inline functions. > > > > I would normally always use a Petsc namespace for this kind of thing, but this library has convenient man pages and is, I think, the best thing out there for implementing these primitives. Wrapping everything in a Petsc* namespace would thus make it less direct to get down to the actual semantics (or a man page). Thus I have half a mind to treat it like MPI and just provide non-threaded implementations in petscck.h when !defined(PETSC_HAVE_CONCURRENCYKIT). Is this a bad idea? > > I can live with it. You, of course, are providing a --download-ck before writing a single line of code that uses ck. > > I agree. Useless wrappers (TaoVec, TrilinosCommStuff) just clutter code and do not expand functionality. But maybe next week MPI won't be used any more and we have to be prepared for that day. Barry > > What is your opinion of the longevity of support? Will we end up supporting this library? > > 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] concurrencykit
by Matthew Knepley 19 Feb '13

19 Feb '13

On Tue, Feb 19, 2013 at 4:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 19, 2013, at 3:43 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > I've started adding support for using this library for memory primitives > and some basic lock-free data structures. > > > > http://concurrencykit.org/ > > > > Of course when threads are not used, we need some replacement. All the > memory barriers and assignments become trivial and locks disappear so the > no-threading variant is trivial to implement. My question now is whether to > call ck_* functions directly from PETSc source or to always wrap them in > Petsc* namespaced macros and inline functions. > > > > I would normally always use a Petsc namespace for this kind of thing, > but this library has convenient man pages and is, I think, the best thing > out there for implementing these primitives. Wrapping everything in a > Petsc* namespace would thus make it less direct to get down to the actual > semantics (or a man page). Thus I have half a mind to treat it like MPI and > just provide non-threaded implementations in petscck.h when > !defined(PETSC_HAVE_CONCURRENCYKIT). Is this a bad idea? > > I can live with it. You, of course, are providing a --download-ck before > writing a single line of code that uses ck. I agree. Useless wrappers (TaoVec, TrilinosCommStuff) just clutter code and do not expand functionality. What is your opinion of the longevity of support? Will we end up supporting this library? 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