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