[petsc-dev] Vec set a block of values

Sat Apr 21 10:10:18 CDT 2018

On Sat, Apr 21, 2018 at 9:07 AM, Junchao Zhang <jczhang at mcs.anl.gov> wrote:

> 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?
>

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 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/>
>>
>
>

-- 
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/384b25e9/attachment.html>