On Sat, Apr 21, 2018 at 9:07 AM, Junchao Zhang <[email protected]> wrote:
> 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? > 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 <[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/> >> > > -- 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/>
