August 2008 - petsc-dev - mailman3.cels.anl.gov

Re: blocked index sets
by Matthew Knepley 27 Aug '08

27 Aug '08

On Wed, Aug 27, 2008 at 12:06 PM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > So, Do all us agree my proposed fix should be pushed? I'll wait for > Matt comments/complaints... I complain that IS is a fake parallel object. However, if GetSize/GetLocalSize already do this, then yes we should change the ISBlock version as well. Matt > On Wed, Aug 27, 2008 at 1:13 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> On Aug 27, 2008, at 10:23 AM, Matthew Knepley wrote: >> >>> There is no concept of global for IS. They are purely serial. AO is the >>> only >>> global construct with indices. >> >> This is kind of true, and maybe used to be completely true. But IS does >> have a communicator and that communicator can be MPI_COMM_WORLD or >> any parallel communicator. In other words the IS is evolving to be an >> object >> that can be parallel in the same sense as vecs or mats >> >> There are already ISGetSize() and ISGetLocalSize() so it sure makes sense >> to have the same paradgm for the ISGetBlockSize(). >> >> >> Barry >> >> Originally IS had no parallel concept, then we added the ISGetSize/LocalSize >> but forgot to do it for the ISBlock... >> >> >>> >>> >>> Matt >>> >>> On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <dalcinl(a)gmail.com> >>> wrote: >>>> >>>> I believe we have to review the interface of ISBlock. Currently, >>>> ISBlockGetSize() return the number of LOCAL block indices. This is not >>>> consistent with other naming conventions for getting local and glocal >>>> sizes. I propose to change this to the following >>>> >>>> 1) change: ISBlockGetSize() returns the number global blocks >>>> 2) addition: ISBlockGetLocalSize() return the number of local blocks >>>> >>>> Comments? >>>> >>>> >>>> -- >>>> Lisandro Dalcï¿½n >>>> --------------- >>>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >>>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >>>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>>> Tel/Fax: +54-(0)342-451.1594 >>>> >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- 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: blocked index sets
by Lisandro Dalcin 27 Aug '08

27 Aug '08

So, Do all us agree my proposed fix should be pushed? I'll wait for Matt comments/complaints... On Wed, Aug 27, 2008 at 1:13 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Aug 27, 2008, at 10:23 AM, Matthew Knepley wrote: > >> There is no concept of global for IS. They are purely serial. AO is the >> only >> global construct with indices. > > This is kind of true, and maybe used to be completely true. But IS does > have a communicator and that communicator can be MPI_COMM_WORLD or > any parallel communicator. In other words the IS is evolving to be an > object > that can be parallel in the same sense as vecs or mats > > There are already ISGetSize() and ISGetLocalSize() so it sure makes sense > to have the same paradgm for the ISGetBlockSize(). > > > Barry > > Originally IS had no parallel concept, then we added the ISGetSize/LocalSize > but forgot to do it for the ISBlock... > > >> >> >> Matt >> >> On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <dalcinl(a)gmail.com> >> wrote: >>> >>> I believe we have to review the interface of ISBlock. Currently, >>> ISBlockGetSize() return the number of LOCAL block indices. This is not >>> consistent with other naming conventions for getting local and glocal >>> sizes. I propose to change this to the following >>> >>> 1) change: ISBlockGetSize() returns the number global blocks >>> 2) addition: ISBlockGetLocalSize() return the number of local blocks >>> >>> Comments? >>> >>> >>> -- >>> Lisandro Dalcï¿½n >>> --------------- >>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >>> >>> >> >> >> >> -- >> 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 >> > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: blocked index sets
by Barry Smith 27 Aug '08

27 Aug '08

On Aug 27, 2008, at 10:23 AM, Matthew Knepley wrote: > There is no concept of global for IS. They are purely serial. AO is > the only > global construct with indices. This is kind of true, and maybe used to be completely true. But IS does have a communicator and that communicator can be MPI_COMM_WORLD or any parallel communicator. In other words the IS is evolving to be an object that can be parallel in the same sense as vecs or mats There are already ISGetSize() and ISGetLocalSize() so it sure makes sense to have the same paradgm for the ISGetBlockSize(). Barry Originally IS had no parallel concept, then we added the ISGetSize/ LocalSize but forgot to do it for the ISBlock... > > > Matt > > On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin > <dalcinl(a)gmail.com> wrote: >> I believe we have to review the interface of ISBlock. Currently, >> ISBlockGetSize() return the number of LOCAL block indices. This is >> not >> consistent with other naming conventions for getting local and glocal >> sizes. I propose to change this to the following >> >> 1) change: ISBlockGetSize() returns the number global blocks >> 2) addition: ISBlockGetLocalSize() return the number of local blocks >> >> Comments? >> >> >> -- >> Lisandro Dalcï¿½n >> --------------- >> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >> Tel/Fax: +54-(0)342-451.1594 >> >> > > > > -- > 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: blocked index sets
by Lisandro Dalcin 27 Aug '08

27 Aug '08

On Wed, Aug 27, 2008 at 12:23 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > There is no concept of global for IS. They are purely serial. AO is the only > global construct with indices. Well, I partially agree with you in that point. However, I still believe ISBlockGetSize is a bit confussing. Perhaps we can condensare ISBlockGetSize() and ISBlockGetIndices() in a single call like this: PetscErrorCode ISBlockGetInfo(IS is, PetscInt *n, const PetscInt *idx[]) Getting the actual, 'unmapped' block indices is a rather special call. > On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >> I believe we have to review the interface of ISBlock. Currently, >> ISBlockGetSize() return the number of LOCAL block indices. This is not >> consistent with other naming conventions for getting local and glocal >> sizes. I propose to change this to the following >> >> 1) change: ISBlockGetSize() returns the number global blocks >> 2) addition: ISBlockGetLocalSize() return the number of local blocks >> >> Comments? >> >> >> -- >> Lisandro Dalcï¿½n >> --------------- >> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) >> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) >> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >> Tel/Fax: +54-(0)342-451.1594 >> >> > > > > -- > 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 > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: blocked index sets
by Matthew Knepley 27 Aug '08

27 Aug '08

There is no concept of global for IS. They are purely serial. AO is the only global construct with indices. Matt On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > I believe we have to review the interface of ISBlock. Currently, > ISBlockGetSize() return the number of LOCAL block indices. This is not > consistent with other naming conventions for getting local and glocal > sizes. I propose to change this to the following > > 1) change: ISBlockGetSize() returns the number global blocks > 2) addition: ISBlockGetLocalSize() return the number of local blocks > > Comments? > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- 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

blocked index sets
by Lisandro Dalcin 27 Aug '08

27 Aug '08

I believe we have to review the interface of ISBlock. Currently, ISBlockGetSize() return the number of LOCAL block indices. This is not consistent with other naming conventions for getting local and glocal sizes. I propose to change this to the following 1) change: ISBlockGetSize() returns the number global blocks 2) addition: ISBlockGetLocalSize() return the number of local blocks Comments? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: [petsc4py] What should be the 'default' communicator?
by Barry Smith 26 Aug '08

26 Aug '08

You have to do what you have to do; if this is the only way then it is the only way, so I have to live with it. Barry On Aug 26, 2008, at 8:54 AM, Lisandro Dalcin wrote: > On Tue, Aug 26, 2008 at 10:24 AM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> This seems a fundamental stupidity of python. Why can't you make >> this >> PETSc thing >> be a python class where the default_comm is a property? >> > > In general, such approach is not convenient. Modules are tightly > releated to 'import' statements. Modules provide a 'namespace' for all > stuff you put inside them. > > Barry, see my current inplementation: > > > from petsc4py import PETSc > > saved_comm = PETSc.Sys.getDefaultComm() > PETSc.Sys.setDefaultComm(PETSc.COMM_SELF) > # do stuff.... > PETSc.Sys.setDefaultComm(saved_comm) > > Do it looks too bad?. I do not expect this pattern to be used all over > user code. Trying to hack/emulate what you want (using a class > instance) will complicate too much the implementation, and the final > result could be 'unnatural' for end users. For example, > > from petsc4py.PETSc import Vec, Mat > > is expected to work, but that will not work if 'PETSc' is a class > instance. > > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: [petsc4py] What should be the 'default' communicator?
by Lisandro Dalcin 26 Aug '08

26 Aug '08

On Tue, Aug 26, 2008 at 10:24 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > This seems a fundamental stupidity of python. Why can't you make this > PETSc thing > be a python class where the default_comm is a property? > In general, such approach is not convenient. Modules are tightly releated to 'import' statements. Modules provide a 'namespace' for all stuff you put inside them. Barry, see my current inplementation: from petsc4py import PETSc saved_comm = PETSc.Sys.getDefaultComm() PETSc.Sys.setDefaultComm(PETSc.COMM_SELF) # do stuff.... PETSc.Sys.setDefaultComm(saved_comm) Do it looks too bad?. I do not expect this pattern to be used all over user code. Trying to hack/emulate what you want (using a class instance) will complicate too much the implementation, and the final result could be 'unnatural' for end users. For example, from petsc4py.PETSc import Vec, Mat is expected to work, but that will not work if 'PETSc' is a class instance. -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: [petsc4py] What should be the 'default' communicator?
by Barry Smith 26 Aug '08

26 Aug '08

On Aug 26, 2008, at 8:20 AM, Lisandro Dalcin wrote: > On Tue, Aug 26, 2008 at 12:36 AM, Matthew Knepley > <knepley(a)gmail.com> wrote: >> On Mon, Aug 25, 2008 at 8:13 PM, Barry Smith <bsmith(a)mcs.anl.gov> >> wrote: >>> Can you not overload the assignment = to automatically call >>> whatever >>> fancy setter you want to use? Then you get the simplicity I crave >>> and the >>> safety you desire? >> >> Yes, you can make it a 'property'. > > No, No. 'property' works with instances of some class, but not with > modules. This is a feature I miss from Python. You cannot 'hook' on > attribute assignments in modules. This seems a fundamental stupidity of python. Why can't you make this PETSc thing be a python class where the default_comm is a property? Barry > > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: [petsc4py] What should be the 'default' communicator?
by Lisandro Dalcin 26 Aug '08

26 Aug '08

On Tue, Aug 26, 2008 at 12:36 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Mon, Aug 25, 2008 at 8:13 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> Can you not overload the assignment = to automatically call whatever >> fancy setter you want to use? Then you get the simplicity I crave and the >> safety you desire? > > Yes, you can make it a 'property'. No, No. 'property' works with instances of some class, but not with modules. This is a feature I miss from Python. You cannot 'hook' on attribute assignments in modules. -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0