April 2018 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] broken stuff in next for many days
by Satish Balay 21 Apr '18

21 Apr '18

https://bitbucket.org/petsc/petsc/pull-requests/896/read-xdmf-style-hdf5-fi… Pushed the following [until it gets properly resolved] https://bitbucket.org/petsc/petsc/commits/2baebb300dfeb523617ec9e93c0d7046e… Satish On Sat, 21 Apr 2018, Smith, Barry F. wrote: > > ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/21/examples_nex… > > not ok diff-dm_impls_plex_tutorials-ex5_2a_nsize-8_format-hdf5_xdmf > # 6,9c6,9 > # < [0]: 7 ----> 3 > # < [0]: 7 ----> 4 > # < [0]: 7 ----> 5 > # < [0]: 7 ----> 6 > # --- > # > [0]: 7 ----> 0 > # > [0]: 7 ----> 1 > # > [0]: 8 ----> 1 > # > [0]: 8 ----> 2 > # 11,13c11,16 > # < [0]: 8 ----> 6 > > Is someone working on fixing this or does the branch need to be abandoned and next cleaned, this has been haunting next for way to long. > > Barry > >

1 0

broken stuff in next for many days
by Smith, Barry F. 21 Apr '18

21 Apr '18

ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/21/examples_nex… not ok diff-dm_impls_plex_tutorials-ex5_2a_nsize-8_format-hdf5_xdmf # 6,9c6,9 # < [0]: 7 ----> 3 # < [0]: 7 ----> 4 # < [0]: 7 ----> 5 # < [0]: 7 ----> 6 # --- # > [0]: 7 ----> 0 # > [0]: 7 ----> 1 # > [0]: 8 ----> 1 # > [0]: 8 ----> 2 # 11,13c11,16 # < [0]: 8 ----> 6 Is someone working on fixing this or does the branch need to be abandoned and next cleaned, this has been haunting next for way to long. Barry

1 0

Re: [petsc-dev] Vec set a block of values
by Matthew Knepley 21 Apr '18

21 Apr '18

On Sat, Apr 21, 2018 at 9:07 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > On Sat, Apr 21, 2018 at 7:51 AM, Matthew Knepley <knepley(a)gmail.com> > wrote: > >> On Sat, Apr 21, 2018 at 8:47 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >>> On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <knepley(a)gmail.com> >>> wrote: >>> >>>> On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>> wrote: >>>> >>>>> VecScatter is too heavy (in both coding and runtime) for this simple >>>>> task. I just want to pad a vector loaded from a PetscViewer to match an >>>>> MPIBAIJ matrix. Thus the majority is memcpy, with few neighborhood >>>>> off-processor puts. >>>>> >>>> >>>> Now this makes no sense. You want to "pad" a Vec? What does this mean? >>>> >>>> 1) You want to extend its length, which none of these can do. You have >>>> to VecCreate another vector. >>>> >>>> 2) You want some elements to be zero. Just VecSet(v, 0) before setting >>>> any elements. >>>> >>>> If its not those, want is the operation? >>>> >>> I don't know why no one reply my post to petsc-users. It has background >>> of this question. The word "pad" is also from comments of this example. >>> >>> >>> Subject: How to adapt vectors to matrices loaded from a viewer >>> To: PETSc users list <petsc-users(a)mcs.anl.gov> >>> >>> In a PETSc example (ex10.c >>> <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/e…>) >>> one MatLoad A and then VecLoad b from a viewer. Since one can change mat >>> block size through option -matload_block_size, the code tries to pad b if A >>> and b's sizes mismatch, using the following test >>> >>> 186: MatGetSize(A,&M,NULL); >>> >>> 187: VecGetSize(b,&m); >>> >>> 188: if (M != m) { /* Create a new vector b by padding the old one */ >>> >>> I think the code is wrong. One has to compare local column size of A >>> and local size of b, and if there is a mismatch on ANY processor, then one >>> has to create a new b. >>> My questions are: Are users supposed to take this complexity? Does >>> PETSc provide a neat way to do that, for example, MatVecLoad(A,b,viewer >>> >>> >> That code is nuts and should be deleted. If you know what values the rhs >> should have analytically, then just create it. >> If you need to load it, then load it. The idea that we can "pad" it is >> nonsensical. That should be deleted from the example. >> > Maybe the code should say "load a vector, and then copy to a longer one > and replace the old one ". It looks like we pad the original vector. > So the question is still there: How to write a neat code to copy a vector > to a longer one? > 1) It makes no sense to copy it. What would the values even mean? Just create a vector of the right size. 2) If you do have a notion of what the values mean, USE VecScatter. That is is exactly what it is for. Matt > >> Matt >> >> >>> >>>> Matt >>>> >>>> >>>>> --Junchao Zhang >>>>> >>>>> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>> >>>>>> Junchao, If you need to access off-process values and put them into a >>>>>> new vector, you should use VecScatter. >>>>>> >>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>> >>>>>> > Setting large contiguous blocks of values is not a common use >>>>>> case. In finite elements the values are not contiguous. >>>>>> > >>>>>> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >>>>>> wrote: >>>>>> >> >>>>>> >> I agree the extra overhead can be small, but users are forced to >>>>>> write a loop where one single line gives the best. >>>>>> >> >>>>>> >> --Junchao Zhang >>>>>> >> >>>>>> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. < >>>>>> bsmith(a)mcs.anl.gov> wrote: >>>>>> >> >>>>>> >> When setting values into matrices and vectors we consider the >>>>>> "extra" overhead of needing to pass in the indices for all the values >>>>>> (instead of being able to set an arbitrary block of values without using >>>>>> indices for each one) to be a minimal overhead that we can live with. >>>>>> >> >>>>>> >> Barry >>>>>> >> >>>>>> >> >>>>>> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>>>> wrote: >>>>>> >> > >>>>>> >> > >>>>>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley < >>>>>> knepley(a)gmail.com> wrote: >>>>>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang < >>>>>> jczhang(a)mcs.anl.gov> wrote: >>>>>> >> > To pad a vector, i.e., copy a vector to a new one, I have to >>>>>> call VecSetValue(newb,1,&idx,...) for each element. But to be efficient, >>>>>> what I really needs is to set a block of values in one call. It looks PETSc >>>>>> does not have a routine for that(?). I looked at VecSetValuesBlocked, but >>>>>> it looks it is not for that purpose. >>>>>> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >>>>>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >>>>>> starting at index i? >>>>>> >> > >>>>>> >> > Use VecGetArray(). >>>>>> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new >>>>>> and then restore them? If yes, it does not work since some of the values I >>>>>> want to set might be remote. >>>>>> >> > E.g, I have 4 processors. b's size is 181 and is distributed as >>>>>> 46, 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >>>>>> size 3. >>>>>> >> > >>>>>> >> > >>>>>> >> > Matt >>>>>> >> > >>>>>> >> > --Junchao Zhang >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > -- >>>>>> >> > 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 >>>>>> >> > >>>>>> >> > https://www.cse.buffalo.edu/~knepley/ >>>>>> >> > >>>>>> >> >>>>>> >> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >>>> >>> >>> >> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >> > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] Vec set a block of values
by Junchao Zhang 21 Apr '18

21 Apr '18

On Sat, Apr 21, 2018 at 7:51 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Sat, Apr 21, 2018 at 8:47 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> > wrote: > >> On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <knepley(a)gmail.com> >> wrote: >> >>> On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>> >>>> VecScatter is too heavy (in both coding and runtime) for this simple >>>> task. I just want to pad a vector loaded from a PetscViewer to match an >>>> MPIBAIJ matrix. Thus the majority is memcpy, with few neighborhood >>>> off-processor puts. >>>> >>> >>> Now this makes no sense. You want to "pad" a Vec? What does this mean? >>> >>> 1) You want to extend its length, which none of these can do. You have >>> to VecCreate another vector. >>> >>> 2) You want some elements to be zero. Just VecSet(v, 0) before setting >>> any elements. >>> >>> If its not those, want is the operation? >>> >> I don't know why no one reply my post to petsc-users. It has background >> of this question. The word "pad" is also from comments of this example. >> >> >> Subject: How to adapt vectors to matrices loaded from a viewer >> To: PETSc users list <petsc-users(a)mcs.anl.gov> >> >> In a PETSc example (ex10.c >> <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/e…>) >> one MatLoad A and then VecLoad b from a viewer. Since one can change mat >> block size through option -matload_block_size, the code tries to pad b if A >> and b's sizes mismatch, using the following test >> >> 186: MatGetSize(A,&M,NULL); >> >> 187: VecGetSize(b,&m); >> >> 188: if (M != m) { /* Create a new vector b by padding the old one */ >> >> I think the code is wrong. One has to compare local column size of A >> and local size of b, and if there is a mismatch on ANY processor, then one >> has to create a new b. >> My questions are: Are users supposed to take this complexity? Does >> PETSc provide a neat way to do that, for example, MatVecLoad(A,b,viewer >> >> > That code is nuts and should be deleted. If you know what values the rhs > should have analytically, then just create it. > If you need to load it, then load it. The idea that we can "pad" it is > nonsensical. That should be deleted from the example. > Maybe the code should say "load a vector, and then copy to a longer one and replace the old one ". It looks like we pad the original vector. So the question is still there: How to write a neat code to copy a vector to a longer one? > > Matt > > >> >>> Matt >>> >>> >>>> --Junchao Zhang >>>> >>>> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>> >>>>> Junchao, If you need to access off-process values and put them into a >>>>> new vector, you should use VecScatter. >>>>> >>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>> >>>>> > Setting large contiguous blocks of values is not a common use >>>>> case. In finite elements the values are not contiguous. >>>>> > >>>>> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >>>>> wrote: >>>>> >> >>>>> >> I agree the extra overhead can be small, but users are forced to >>>>> write a loop where one single line gives the best. >>>>> >> >>>>> >> --Junchao Zhang >>>>> >> >>>>> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. < >>>>> bsmith(a)mcs.anl.gov> wrote: >>>>> >> >>>>> >> When setting values into matrices and vectors we consider the >>>>> "extra" overhead of needing to pass in the indices for all the values >>>>> (instead of being able to set an arbitrary block of values without using >>>>> indices for each one) to be a minimal overhead that we can live with. >>>>> >> >>>>> >> Barry >>>>> >> >>>>> >> >>>>> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>>> wrote: >>>>> >> > >>>>> >> > >>>>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley < >>>>> knepley(a)gmail.com> wrote: >>>>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang < >>>>> jczhang(a)mcs.anl.gov> wrote: >>>>> >> > To pad a vector, i.e., copy a vector to a new one, I have to call >>>>> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >>>>> really needs is to set a block of values in one call. It looks PETSc does >>>>> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >>>>> looks it is not for that purpose. >>>>> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >>>>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >>>>> starting at index i? >>>>> >> > >>>>> >> > Use VecGetArray(). >>>>> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new >>>>> and then restore them? If yes, it does not work since some of the values I >>>>> want to set might be remote. >>>>> >> > E.g, I have 4 processors. b's size is 181 and is distributed as >>>>> 46, 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >>>>> size 3. >>>>> >> > >>>>> >> > >>>>> >> > Matt >>>>> >> > >>>>> >> > --Junchao Zhang >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > -- >>>>> >> > 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 >>>>> >> > >>>>> >> > https://www.cse.buffalo.edu/~knepley/ >>>>> >> > >>>>> >> >>>>> >> >>>>> >>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >>> >> >> > > > -- > 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 > > https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >

1 0

Re: [petsc-dev] Vec set a block of values
by Matthew Knepley 21 Apr '18

21 Apr '18

On Sat, Apr 21, 2018 at 8:47 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <knepley(a)gmail.com> > wrote: > >> On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >>> VecScatter is too heavy (in both coding and runtime) for this simple >>> task. I just want to pad a vector loaded from a PetscViewer to match an >>> MPIBAIJ matrix. Thus the majority is memcpy, with few neighborhood >>> off-processor puts. >>> >> >> Now this makes no sense. You want to "pad" a Vec? What does this mean? >> >> 1) You want to extend its length, which none of these can do. You have to >> VecCreate another vector. >> >> 2) You want some elements to be zero. Just VecSet(v, 0) before setting >> any elements. >> >> If its not those, want is the operation? >> > I don't know why no one reply my post to petsc-users. It has background of > this question. The word "pad" is also from comments of this example. > > > Subject: How to adapt vectors to matrices loaded from a viewer > To: PETSc users list <petsc-users(a)mcs.anl.gov> > > In a PETSc example (ex10.c > <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/e…>) > one MatLoad A and then VecLoad b from a viewer. Since one can change mat > block size through option -matload_block_size, the code tries to pad b if A > and b's sizes mismatch, using the following test > > 186: MatGetSize(A,&M,NULL); > > 187: VecGetSize(b,&m); > > 188: if (M != m) { /* Create a new vector b by padding the old one */ > > I think the code is wrong. One has to compare local column size of A and > local size of b, and if there is a mismatch on ANY processor, then one has > to create a new b. > My questions are: Are users supposed to take this complexity? Does PETSc > provide a neat way to do that, for example, MatVecLoad(A,b,viewer > > That code is nuts and should be deleted. If you know what values the rhs should have analytically, then just create it. If you need to load it, then load it. The idea that we can "pad" it is nonsensical. That should be deleted from the example. Matt > >> Matt >> >> >>> --Junchao Zhang >>> >>> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> >>>> Junchao, If you need to access off-process values and put them into a >>>> new vector, you should use VecScatter. >>>> >>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>> >>>> > Setting large contiguous blocks of values is not a common use case. >>>> In finite elements the values are not contiguous. >>>> > >>>> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >>>> wrote: >>>> >> >>>> >> I agree the extra overhead can be small, but users are forced to >>>> write a loop where one single line gives the best. >>>> >> >>>> >> --Junchao Zhang >>>> >> >>>> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> >>>> wrote: >>>> >> >>>> >> When setting values into matrices and vectors we consider the >>>> "extra" overhead of needing to pass in the indices for all the values >>>> (instead of being able to set an arbitrary block of values without using >>>> indices for each one) to be a minimal overhead that we can live with. >>>> >> >>>> >> Barry >>>> >> >>>> >> >>>> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>> wrote: >>>> >> > >>>> >> > >>>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley < >>>> knepley(a)gmail.com> wrote: >>>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang < >>>> jczhang(a)mcs.anl.gov> wrote: >>>> >> > To pad a vector, i.e., copy a vector to a new one, I have to call >>>> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >>>> really needs is to set a block of values in one call. It looks PETSc does >>>> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >>>> looks it is not for that purpose. >>>> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >>>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >>>> starting at index i? >>>> >> > >>>> >> > Use VecGetArray(). >>>> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new and >>>> then restore them? If yes, it does not work since some of the values I want >>>> to set might be remote. >>>> >> > E.g, I have 4 processors. b's size is 181 and is distributed as >>>> 46, 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >>>> size 3. >>>> >> > >>>> >> > >>>> >> > Matt >>>> >> > >>>> >> > --Junchao Zhang >>>> >> > >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > 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 >>>> >> > >>>> >> > https://www.cse.buffalo.edu/~knepley/ >>>> >> > >>>> >> >>>> >> >>>> >>> >>> >> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >> > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] Vec set a block of values
by Junchao Zhang 21 Apr '18

21 Apr '18

On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> > wrote: > >> VecScatter is too heavy (in both coding and runtime) for this simple >> task. I just want to pad a vector loaded from a PetscViewer to match an >> MPIBAIJ matrix. Thus the majority is memcpy, with few neighborhood >> off-processor puts. >> > > Now this makes no sense. You want to "pad" a Vec? What does this mean? > > 1) You want to extend its length, which none of these can do. You have to > VecCreate another vector. > > 2) You want some elements to be zero. Just VecSet(v, 0) before setting any > elements. > > If its not those, want is the operation? > I don't know why no one reply my post to petsc-users. It has background of this question. The word "pad" is also from comments of this example. Subject: How to adapt vectors to matrices loaded from a viewer To: PETSc users list <petsc-users(a)mcs.anl.gov> In a PETSc example (ex10.c <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/e…>) one MatLoad A and then VecLoad b from a viewer. Since one can change mat block size through option -matload_block_size, the code tries to pad b if A and b's sizes mismatch, using the following test 186: MatGetSize(A,&M,NULL); 187: VecGetSize(b,&m); 188: if (M != m) { /* Create a new vector b by padding the old one */ I think the code is wrong. One has to compare local column size of A and local size of b, and if there is a mismatch on ANY processor, then one has to create a new b. My questions are: Are users supposed to take this complexity? Does PETSc provide a neat way to do that, for example, MatVecLoad(A,b,viewer) > Matt > > >> --Junchao Zhang >> >> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >>> Junchao, If you need to access off-process values and put them into a >>> new vector, you should use VecScatter. >>> >>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>> >>> > Setting large contiguous blocks of values is not a common use case. >>> In finite elements the values are not contiguous. >>> > >>> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >>> wrote: >>> >> >>> >> I agree the extra overhead can be small, but users are forced to >>> write a loop where one single line gives the best. >>> >> >>> >> --Junchao Zhang >>> >> >>> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> >>> wrote: >>> >> >>> >> When setting values into matrices and vectors we consider the >>> "extra" overhead of needing to pass in the indices for all the values >>> (instead of being able to set an arbitrary block of values without using >>> indices for each one) to be a minimal overhead that we can live with. >>> >> >>> >> Barry >>> >> >>> >> >>> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>> >> > >>> >> > >>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <knepley(a)gmail.com> >>> wrote: >>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>> >> > To pad a vector, i.e., copy a vector to a new one, I have to call >>> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >>> really needs is to set a block of values in one call. It looks PETSc does >>> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >>> looks it is not for that purpose. >>> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >>> starting at index i? >>> >> > >>> >> > Use VecGetArray(). >>> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new and >>> then restore them? If yes, it does not work since some of the values I want >>> to set might be remote. >>> >> > E.g, I have 4 processors. b's size is 181 and is distributed as 46, >>> 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >>> size 3. >>> >> > >>> >> > >>> >> > Matt >>> >> > >>> >> > --Junchao Zhang >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > 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 >>> >> > >>> >> > https://www.cse.buffalo.edu/~knepley/ >>> >> > >>> >> >>> >> >>> >> >> > > > -- > 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 > > https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >

1 0

Re: [petsc-dev] Vec set a block of values
by Matthew Knepley 21 Apr '18

21 Apr '18

On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > VecScatter is too heavy (in both coding and runtime) for this simple task. > I just want to pad a vector loaded from a PetscViewer to match an MPIBAIJ > matrix. Thus the majority is memcpy, with few neighborhood off-processor > puts. > Now this makes no sense. You want to "pad" a Vec? What does this mean? 1) You want to extend its length, which none of these can do. You have to VecCreate another vector. 2) You want some elements to be zero. Just VecSet(v, 0) before setting any elements. If its not those, want is the operation? Matt > --Junchao Zhang > > On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> Junchao, If you need to access off-process values and put them into a >> new vector, you should use VecScatter. >> >> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> >> > Setting large contiguous blocks of values is not a common use case. >> In finite elements the values are not contiguous. >> > >> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >> wrote: >> >> >> >> I agree the extra overhead can be small, but users are forced to write >> a loop where one single line gives the best. >> >> >> >> --Junchao Zhang >> >> >> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> >> wrote: >> >> >> >> When setting values into matrices and vectors we consider the >> "extra" overhead of needing to pass in the indices for all the values >> (instead of being able to set an arbitrary block of values without using >> indices for each one) to be a minimal overhead that we can live with. >> >> >> >> Barry >> >> >> >> >> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >> > >> >> > >> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <knepley(a)gmail.com> >> wrote: >> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >> > To pad a vector, i.e., copy a vector to a new one, I have to call >> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >> really needs is to set a block of values in one call. It looks PETSc does >> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >> looks it is not for that purpose. >> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >> starting at index i? >> >> > >> >> > Use VecGetArray(). >> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new and >> then restore them? If yes, it does not work since some of the values I want >> to set might be remote. >> >> > E.g, I have 4 processors. b's size is 181 and is distributed as 46, >> 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >> size 3. >> >> > >> >> > >> >> > Matt >> >> > >> >> > --Junchao Zhang >> >> > >> >> > >> >> > >> >> > -- >> >> > 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 >> >> > >> >> > https://www.cse.buffalo.edu/~knepley/ >> >> > >> >> >> >> >> > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] Vec set a block of values
by Junchao Zhang 20 Apr '18

20 Apr '18

I don't care the little extra overhead. I just feel the avoidable loop in the user code a bit ugly. --Junchao Zhang On Fri, Apr 20, 2018 at 4:11 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > I would just use VecSetValues() since almost all values are local it > will be scalable and a little extra time in setting values is not a big > deal for this test code. > > Barry > > > > On Apr 20, 2018, at 4:09 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > > Junchao Zhang <jczhang(a)mcs.anl.gov> writes: > > > >> VecScatter is too heavy (in both coding and runtime) for this simple > task. > >> I just want to pad a vector loaded from a PetscViewer to match an > MPIBAIJ > >> matrix. Thus the majority is memcpy, with few neighborhood off-processor > >> puts. > > > > At what address do those puts go, how do you avoid race conditions from > > multiple processors having overlapping neighborhoods, and how does the > > recipient know that the put has completed? Just use VecScatter. It > > could be optimized to recognize contiguous runs above a certain size and > > convert to memcpy. > > > >> --Junchao Zhang > >> > >> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > >>> Junchao, If you need to access off-process values and put them into a > >>> new vector, you should use VecScatter. > >>> > >>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > >>> > >>>> Setting large contiguous blocks of values is not a common use case. > In > >>> finite elements the values are not contiguous. > >>>> > >>>>> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> > >>> wrote: > >>>>> > >>>>> I agree the extra overhead can be small, but users are forced to > write > >>> a loop where one single line gives the best. > >>>>> > >>>>> --Junchao Zhang > >>>>> > >>>>> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov > > > >>> wrote: > >>>>> > >>>>> When setting values into matrices and vectors we consider the > >>> "extra" overhead of needing to pass in the indices for all the values > >>> (instead of being able to set an arbitrary block of values without > using > >>> indices for each one) to be a minimal overhead that we can live with. > >>>>> > >>>>> Barry > >>>>> > >>>>> > >>>>>> On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> > >>> wrote: > >>>>>> > >>>>>> > >>>>>> On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <knepley(a)gmail.com > > > >>> wrote: > >>>>>> On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov > > > >>> wrote: > >>>>>> To pad a vector, i.e., copy a vector to a new one, I have to call > >>> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, > what I > >>> really needs is to set a block of values in one call. It looks PETSc > does > >>> not have a routine for that(?). I looked at VecSetValuesBlocked, but it > >>> looks it is not for that purpose. > >>>>>> Should we have something like VecSetValuesBlock(Vec v,PetscInt > >>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values > >>> starting at index i? > >>>>>> > >>>>>> Use VecGetArray(). > >>>>>> Did you mean VecGetArray b and newb, do a memcpy from b to new and > >>> then restore them? If yes, it does not work since some of the values I > want > >>> to set might be remote. > >>>>>> E.g, I have 4 processors. b's size is 181 and is distributed as 46, > >>> 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block > >>> size 3. > >>>>>> > >>>>>> > >>>>>> Matt > >>>>>> > >>>>>> --Junchao Zhang > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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 > >>>>>> > >>>>>> https://www.cse.buffalo.edu/~knepley/ > >>>>>> > >>>>> > >>>>> > >>> > >

1 0

Re: [petsc-dev] Vec set a block of values
by Smith, Barry F. 20 Apr '18

20 Apr '18

I would just use VecSetValues() since almost all values are local it will be scalable and a little extra time in setting values is not a big deal for this test code. Barry > On Apr 20, 2018, at 4:09 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Junchao Zhang <jczhang(a)mcs.anl.gov> writes: > >> VecScatter is too heavy (in both coding and runtime) for this simple task. >> I just want to pad a vector loaded from a PetscViewer to match an MPIBAIJ >> matrix. Thus the majority is memcpy, with few neighborhood off-processor >> puts. > > At what address do those puts go, how do you avoid race conditions from > multiple processors having overlapping neighborhoods, and how does the > recipient know that the put has completed? Just use VecScatter. It > could be optimized to recognize contiguous runs above a certain size and > convert to memcpy. > >> --Junchao Zhang >> >> On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >>> Junchao, If you need to access off-process values and put them into a >>> new vector, you should use VecScatter. >>> >>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>> >>>> Setting large contiguous blocks of values is not a common use case. In >>> finite elements the values are not contiguous. >>>> >>>>> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >>> wrote: >>>>> >>>>> I agree the extra overhead can be small, but users are forced to write >>> a loop where one single line gives the best. >>>>> >>>>> --Junchao Zhang >>>>> >>>>> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> >>> wrote: >>>>> >>>>> When setting values into matrices and vectors we consider the >>> "extra" overhead of needing to pass in the indices for all the values >>> (instead of being able to set an arbitrary block of values without using >>> indices for each one) to be a minimal overhead that we can live with. >>>>> >>>>> Barry >>>>> >>>>> >>>>>> On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>>>>> >>>>>> >>>>>> On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <knepley(a)gmail.com> >>> wrote: >>>>>> On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>>>>> To pad a vector, i.e., copy a vector to a new one, I have to call >>> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >>> really needs is to set a block of values in one call. It looks PETSc does >>> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >>> looks it is not for that purpose. >>>>>> Should we have something like VecSetValuesBlock(Vec v,PetscInt >>> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >>> starting at index i? >>>>>> >>>>>> Use VecGetArray(). >>>>>> Did you mean VecGetArray b and newb, do a memcpy from b to new and >>> then restore them? If yes, it does not work since some of the values I want >>> to set might be remote. >>>>>> E.g, I have 4 processors. b's size is 181 and is distributed as 46, >>> 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >>> size 3. >>>>>> >>>>>> >>>>>> Matt >>>>>> >>>>>> --Junchao Zhang >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>> >>>>> >>>>> >>>

1 0

Re: [petsc-dev] Vec set a block of values
by Jed Brown 20 Apr '18

20 Apr '18

Junchao Zhang <jczhang(a)mcs.anl.gov> writes: > VecScatter is too heavy (in both coding and runtime) for this simple task. > I just want to pad a vector loaded from a PetscViewer to match an MPIBAIJ > matrix. Thus the majority is memcpy, with few neighborhood off-processor > puts. At what address do those puts go, how do you avoid race conditions from multiple processors having overlapping neighborhoods, and how does the recipient know that the put has completed? Just use VecScatter. It could be optimized to recognize contiguous runs above a certain size and convert to memcpy. > --Junchao Zhang > > On Fri, Apr 20, 2018 at 3:57 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> Junchao, If you need to access off-process values and put them into a >> new vector, you should use VecScatter. >> >> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> >> > Setting large contiguous blocks of values is not a common use case. In >> finite elements the values are not contiguous. >> > >> >> On Apr 20, 2018, at 3:45 PM, Zhang, Junchao <jczhang(a)mcs.anl.gov> >> wrote: >> >> >> >> I agree the extra overhead can be small, but users are forced to write >> a loop where one single line gives the best. >> >> >> >> --Junchao Zhang >> >> >> >> On Fri, Apr 20, 2018 at 3:36 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> >> wrote: >> >> >> >> When setting values into matrices and vectors we consider the >> "extra" overhead of needing to pass in the indices for all the values >> (instead of being able to set an arbitrary block of values without using >> indices for each one) to be a minimal overhead that we can live with. >> >> >> >> Barry >> >> >> >> >> >> > On Apr 20, 2018, at 3:33 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >> > >> >> > >> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <knepley(a)gmail.com> >> wrote: >> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >> > To pad a vector, i.e., copy a vector to a new one, I have to call >> VecSetValue(newb,1,&idx,...) for each element. But to be efficient, what I >> really needs is to set a block of values in one call. It looks PETSc does >> not have a routine for that(?). I looked at VecSetValuesBlocked, but it >> looks it is not for that purpose. >> >> > Should we have something like VecSetValuesBlock(Vec v,PetscInt >> i,PetscInt cnt,PetscScalar *value, InsertMode mode) to set cnt values >> starting at index i? >> >> > >> >> > Use VecGetArray(). >> >> > Did you mean VecGetArray b and newb, do a memcpy from b to new and >> then restore them? If yes, it does not work since some of the values I want >> to set might be remote. >> >> > E.g, I have 4 processors. b's size is 181 and is distributed as 46, >> 45,45,45, newb is distributed as 48,45,45,45 to match a matrix of block >> size 3. >> >> > >> >> > >> >> > Matt >> >> > >> >> > --Junchao Zhang >> >> > >> >> > >> >> > >> >> > -- >> >> > 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 >> >> > >> >> > https://www.cse.buffalo.edu/~knepley/ >> >> > >> >> >> >> >>

1 0