On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <[email protected]> wrote:
> On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <[email protected]> > 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 <[email protected]> In a PETSc example (ex10.c <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/ex10.c.html>) 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 <[email protected]> wrote: >> >>> Junchao, If you need to access off-process values and put them into a >>> new vector, you should use VecScatter. >>> >>> "Smith, Barry F." <[email protected]> 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 <[email protected]> >>> 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. <[email protected]> >>> 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 <[email protected]> >>> wrote: >>> >> > >>> >> > >>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <[email protected]> >>> wrote: >>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <[email protected]> >>> 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/> >
