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

[Satish Balay]

Ok. added 1-patch-vecdotnorm2-table.diff [with minor cleanup] to
petsc-31 and merged with petsc-dev.

Satish

On Thu, 8 Jul 2010, Barry Smith wrote:

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