[petsc-dev] [petsc-maint #49008] Problems with VecDotNorm2

[Barry Smith]

  I think you should stick to one patch for both. Rather than having two different pieces of code to deal with if problems come up.



   Barry

On Jul 8, 2010, at 10:07 PM, Satish Balay wrote:

> Ah - I see you wanted me to use 1-patch-vecdotnorm2-table.diff - but I
> used 2-patch-vecdotnorm2-query.diff.
> 
> I can do as Jose suggested: 2-patch-vecdotnorm2-query.diff to
> petsc-3.1 and pull/merge/change petsc-dev to
> 2-patch-vecdotnorm2-query.diff
> 
> Satish
> 
> On Thu, 8 Jul 2010, Barry Smith wrote:
> 
>> 
>>  Ok, let's go with it then.
>> 
>>   Thanks
>> 
>>  Barry
>> 
>> On Jul 8, 2010, at 6:59 PM, Satish Balay wrote:
>> 
>>> Barry,
>>> 
>>> I've added patch-vecdotnorm2-query.diff to petsc-31 and ran a couple
>>> of builds with tests - and they ran fine.
>>> 
>>> Satish
>>> 
>>> On Thu, 8 Jul 2010, Barry Smith wrote:
>>> 
>>>> 
>>>>  Satish,
>>>> 
>>>>   Can you try to apply solution 1 to 3.1 and see if the tests are ok?
>>>> 
>>>>  Barry
>>>> 
>>>> On Jul 8, 2010, at 9:56 AM, Jose E. Roman wrote:
>>>> 
>>>>> 
>>>>> On 07/07/2010, Barry Smith wrote:
>>>>> 
>>>>>> 
>>>>>> On Jul 6, 2010, at 9:49 AM, Jose E. Roman wrote:
>>>>>> 
>>>>>>> Dear all,
>>>>>>> 
>>>>>>> We at SLEPc have included a custom implementation of vectors that emulates block vectors in the spirit of PetscExt: v=[v1' v2']' where v1 and v2 are PETSc vectors. This is required for some new SLEPc solvers. With this new type of vectors, we avoid the VecGetArray/VecRestoreArray operations, which would imply array copies, and overload any other required operation. The only place outside SLEPc where these vectors are used is as arguments to KSPSolve.
>>>>>>> 
>>>>>>> The problem is VecDotNorm2, which is used in KSPSolve_BCGS and KSPSolve_GCR_cycle and invokes VecGetArray. VecDotNorm2 cannot be overloaded as the other functions, since it is not included in the _VecOps table. Therefore we cannot use KSP=bcgsl with our new solvers. A fix for us would be to promote VecDotNorm2 to be a true Vec operation
>>>>>> 
>>>>>> 
>>>>>> I have no objection to upgrading VecDotNorm2() to be a virtual function. 
>>>>>> 
>>>>>> 
>>>>>>> . If possible, it would be nice that the fix would be included in petsc-3.1.
>>>>>> 
>>>>>> We really don't like to make such a big change in a patch but if you make the change the change to 3.1 and test it then I have no objection.
>>>>>> 
>>>>>> Barry
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Jose
>>>>>>> 
>>>>>>> PS. We plan to release slepc-3.1 in a few weeks.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> I am attaching two possible solutions to our problem.
>>>>> 
>>>>> 1) patch-vecdotnorm2-table.diff --> this is the solution suggested initially. The problem is that if it is included in petsc-3.1 then the ABI will be incompatible with previous patches.
>>>>> 
>>>>> 2) patch-vecdotnorm2-query.diff --> this uses PetscObjectQueryFunction so that the functionality can be replaced from outside. You may not like this hack but it maintains ABI compatibility.
>>>>> 
>>>>> You may decide to put 2) into petsc-release-3.1 and 1) into petsc-dev.
>>>>> 
>>>>> Note that both patchfiles are with respect to petsc-release-3.1.
>>>>> 
>>>>> Cheers,
>>>>> Jose
>>>>> 
>>>>> 
>>>>> <patch-vecdotnorm2-query.diff><patch-vecdotnorm2-table.diff>
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>