[petsc-dev] Vec set a block of values

[Junchao Zhang]

On Sat, Apr 21, 2018 at 7:51 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Sat, Apr 21, 2018 at 8:47 AM, Junchao Zhang <jczhang at mcs.anl.gov>
> wrote:
>
>> On Sat, Apr 21, 2018 at 6:21 AM, Matthew Knepley <knepley at gmail.com>
>> wrote:
>>
>>> On Fri, Apr 20, 2018 at 5:02 PM, Junchao Zhang <jczhang at 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 at mcs.anl.gov>
>>
>>  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 <jed at 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 at 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 at 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 at 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 at mcs.anl.gov>
>>>>> wrote:
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Apr 20, 2018 at 3:18 PM, Matthew Knepley <
>>>>> knepley at gmail.com> wrote:
>>>>> >> > On Fri, Apr 20, 2018 at 4:10 PM, Junchao Zhang <
>>>>> jczhang at 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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180421/b6e1eca4/attachment-0001.html>