On Sat, Apr 21, 2018 at 7:51 AM, Matthew Knepley <[email protected]> wrote:
> On Sat, Apr 21, 2018 at 8:47 AM, Junchao Zhang <[email protected]> > wrote: > >> 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 >> >> > 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 <[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/> >>> >> >> > > > -- > 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/> >
