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

Re: Block matrices and Schur complement preconditioning
by Jed Brown 28 Aug '08

28 Aug '08

On Wed 2008-08-27 16:42, Matthew Knepley wrote: > Just so I can remove this from my todo mail pile, it appears Barry is > doing this. > The actually Schur stuff is a new KSP thing so we do not link Mat to KSP, but > it should work as you want. I noticed this going in. I have something similar, though it was targeting my partially matrix-free case (Barry's is more general so I'll start using it). My rambling was more about attaching an auxiliary matrix which the preconditioner uses to precondition a solve with the Schur complement. PetscObjectCompose() will work fine for this. The other direction (the preconditioner telling the assembly code to assemble this auxiliary form) is an application-specific thing. Thanks, Jed

1 0

Re: Block matrices and Schur complement preconditioning
by Matthew Knepley 27 Aug '08

27 Aug '08

Just so I can remove this from my todo mail pile, it appears Barry is doing this. The actually Schur stuff is a new KSP thing so we do not link Mat to KSP, but it should work as you want. Matt On Mon, Aug 11, 2008 at 4:16 PM, Jed Brown <jed(a)59a2.org> wrote: > For context, I'm thinking of LNKS optimization or coupled indefinite > systems, perhaps with many fields, where the Jacobian is applied matrix-free > (using a MatShell in my usage). In these circumstances, it isn't useful to > actually form all the blocks in the Jacobian when constructing the > preconditioning matrix, just those which are the operator or preconditioning > matrix in a KSP inside the Schur complement/reduced space preconditioner. > In order to make the preconditioner slightly more generic, it would be nice > to have a matrix type which is really just a wrapper for the blocks which > are actually needed by the preconditioner. For a simple concrete example, > consider a mixed discretization of the Stokes problem J = [A B'; B 0] where > J is applied matrix-free. For preconditioning, we'll need an approximate > Schur complement S = -B \tilde{A^{-1}} B' where \tilde{A^{-1}} may be > V-cycle of AMG applied to \hat{A} (an approximation to A) which is the > only matrix which needs to be actually formed. Normally the pressure mass > matrix M would also be formed to precondition S. Now we could define the > preconditioning matrix P = [\hat{A} 0; 0 M], but I don't like it. > > Of course \hat{A} and M need not have the same matrix type, but it seems > logical to assemble them in the Jacobian assembly function. What I > currently do is to put them in the PCShell context and assemble them in > PCSetUp(), but this means that the PC needs access to the problem > description. We could put them in P = [\hat{A} 0; 0 M] (of type MatShell) > and extract the pieces with MatGetSubMatrix(), but it seems to me that > MatGetSubMatrix() ought to be able to succeed with any valid pair of IS. > > So perhaps it would be useful to have another function MatGetSubBlock() > which just takes a pair of integers and returns the block if it is > available. That is, we could have MatGetSubBlock(P,0,0,&Ahat) give the > explicit viscosity matrix and MatGetSubBlock(J,1,0,&B) give a MatShell which > implements B, but MatGetSubBlock(P,1,0,&Bhat) return NULL since an explicit > form of that matrix is not available (or it could return the MatShell B). > On the other hand, what should MatGetSubBlock(P,1,1,&C) give? Logically, it > should be the zero matrix or NULL, but the preconditioner needs to get > access to M somehow. So it looks like we are back to the original situation > where the assembly code needs to know details about the preconditioner or > the preconditioner needs to know how to assemble the matrices it needs. We > can get slightly more separation by using P as a container for those > matrices that the preconditioner would need, but now its looking like P > isn't a matrix at all (it wouldn't really make sense to implement > MatMult()). > > Any ideas for a better way? > > Jed > -- 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 Barry Smith 27 Aug '08

27 Aug '08

On Aug 27, 2008, at 2:26 PM, Matthew Knepley wrote: > On Wed, Aug 27, 2008 at 2:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> Even if an object (class) has NO collective operations, if, when >> you use >> that object, you must have partners are all >> other processes in a MPI_Comm then I think it is a good approach to >> have >> that be a parallel >> object that shares the comm. > > I will not suggest that we go back on IS now. However, I am not sure > I buy the > above argument. I see IS as just managing a list of integers, and > maybe reporting > some local properties. All the parallel actions are done by different > objects, like > Scatter or Mat. This is different from KSP or Vec which have natural > parallel actions. > I understand your explanation and appreciate it. As I continue to screw around with the "multi-physics" stuff I envision more use of the IS where manipulations with the IS don't always occur in the context of a Vec or Mat, in that case having the comm within the IS is very powerful. (It may turn out that this never really happens so we could remove the comm from the IS, I can't say yet.) Barry > 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: blocked index sets
by Matthew Knepley 27 Aug '08

27 Aug '08

On Wed, Aug 27, 2008 at 2:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Even if an object (class) has NO collective operations, if, when you use > that object, you must have partners are all > other processes in a MPI_Comm then I think it is a good approach to have > that be a parallel > object that shares the comm. I will not suggest that we go back on IS now. However, I am not sure I buy the above argument. I see IS as just managing a list of integers, and maybe reporting some local properties. All the parallel actions are done by different objects, like Scatter or Mat. This is different from KSP or Vec which have natural parallel actions. 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: blocked index sets
by Barry Smith 27 Aug '08

27 Aug '08

On Aug 27, 2008, at 1:34 PM, Dmitry Karpeev wrote: > I would say that IS appears to be a *non-scalable* parallel object, > since the only parallel call > available for it seems to be ISAllGather (and variants). Yes this is non-scalable. Vecs have some nonscalable stuff in them also. > > It also seems to me that the real use for an IS is as input to the > ISLocalToGlobalMapping routines and it is > the mapping object that is truly global. Actually they were created for VecScatterCreate() and MatGetSubMatrices(), in both these cases it is natural to think of the IS as a parallel object (though I agree you can also think of it as not a parallel object). For ISLocalToGlobalMapping() create, I agree there is nothing that would make one demand that the IS is parallel. > > > As a test for IS being global, can one imagine a circumstance when > the same IS > can be used with two different mappings which carry different comms? I don't understand this test. On the processes that are in both comms you could use the same (sequential) IS, for example, to create a VecScatter. Possible but unliikely. Even if an object (class) has NO collective operations, if, when you use that object, you must have partners are all other processes in a MPI_Comm then I think it is a good approach to have that be a parallel object that shares the comm. Barry > > > I also want to point out that, in retrospect, Sieve is an evolution > of the IS/ISLocalToGlobalMapping > set of ideas. > > Dmitry. > > On Wed, Aug 27, 2008 at 1:16 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote: > > > >> 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. > > > > In what way is IS a fake parallel object? Maybe we can resolve > > your concern about it being a fake parallel object. > > I said fake because it has a single collective operation (or even one > with communication). > We even use IS in situations where GetSize() makes no sense, or at > least are not > careful about the comm used. Also, none of the other functions work > over the comm. > For instance, the ISIsPermutation() or ISSorted() do not look at the > indices collectively. > > Matt > > > Barry > > > > > >> 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 > >> > > > > > > > > -- > 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 Barry Smith 27 Aug '08

27 Aug '08

On Aug 27, 2008, at 1:16 PM, Matthew Knepley wrote: > On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> >> On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote: >> >>> 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. >> >> In what way is IS a fake parallel object? Maybe we can resolve >> your concern about it being a fake parallel object. > > I said fake because it has a single collective operation (or even one > with communication). > We even use IS in situations where GetSize() makes no sense, or at > least are not > careful about the comm used. Where are these cases? They should be fixed. > Also, none of the other functions work > over the comm. > For instance, the ISIsPermutation() or ISSorted() do not look at the > indices collectively. This is a legitimate complaint. It could be some of these things should be turned off (generate errors) when used with parallel IS. Or maybe they need to be fixed to work correctly with parallel IS. I note that all the ISCreatexx() routines make MPI collective calls, to me this clearly cements them as parallel objects. One could argue that they should not have collective calls and thus be only parallel. But in the current form they are parallel (maybe crappy parallel) so we should either fix anything related to parallel that is wrong or drop all the parallel stuff completely. I vote for fixing them up and making them respectable parallel objects. Barry > > > Matt > >> Barry >> >> >>> 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 >>> >> >> > > > > -- > 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 Dmitry Karpeev 27 Aug '08

27 Aug '08

I would say that IS appears to be a *non-scalable* parallel object, since the only parallel call available for it seems to be ISAllGather (and variants). It also seems to me that the real use for an IS is as input to the ISLocalToGlobalMapping routines and it is the mapping object that is truly global. As a test for IS being global, can one imagine a circumstance when the same IS can be used with two different mappings which carry different comms? I also want to point out that, in retrospect, Sieve is an evolution of the IS/ISLocalToGlobalMapping set of ideas. Dmitry. On Wed, Aug 27, 2008 at 1:16 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote: > > > >> 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. > > > > In what way is IS a fake parallel object? Maybe we can resolve > > your concern about it being a fake parallel object. > > I said fake because it has a single collective operation (or even one > with communication). > We even use IS in situations where GetSize() makes no sense, or at least > are not > careful about the comm used. Also, none of the other functions work > over the comm. > For instance, the ISIsPermutation() or ISSorted() do not look at the > indices collectively. > > Matt > > > Barry > > > > > >> 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 > >> > > > > > > > > -- > 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 Matthew Knepley 27 Aug '08

27 Aug '08

On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote: > >> 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. > > In what way is IS a fake parallel object? Maybe we can resolve > your concern about it being a fake parallel object. I said fake because it has a single collective operation (or even one with communication). We even use IS in situations where GetSize() makes no sense, or at least are not careful about the comm used. Also, none of the other functions work over the comm. For instance, the ISIsPermutation() or ISSorted() do not look at the indices collectively. Matt > Barry > > >> 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 >> > > -- 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 Barry Smith 27 Aug '08

27 Aug '08

On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote: > 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. In what way is IS a fake parallel object? Maybe we can resolve your concern about it being a fake parallel object. Barry > 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

On Wed, Aug 27, 2008 at 2:13 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > 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. OK, I'll then push a fix ASAP. > 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 > > -- 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