Hi Chetan, thanks for the updated patch. I've commited it here: https://bitbucket.org/petsc/petsc/commits/3c0b9f6fee0dc356fda99b643b018c35feeba883 and merged it to next. It will be merged to master after it passes our nightly tests.
Best regards, Karli On 03/19/2013 06:22 PM, Chetan Jhurani wrote: > Thanks Karl. The attached patch fixes the two issues you > mentioned. > > I think the file extension comment in the code was a remnant > and is not really needed. I've removed it. > > I have also removed CUSPARRAY macro from petsccusp.h and > used the full class name. There are some implementation > files that still use the macro. But fixing them is probably not > in the spirit of the public header cleanup effort and so I > have not touched them. > > Chetan > >> -----Original Message----- >> From: Karl Rupp [mailto:rupp at mcs.anl.gov] >> Sent: Tuesday, March 19, 2013 3:25 PM >> To: For users of the development version of PETSc >> Cc: Chetan Jhurani >> Subject: Re: [petsc-dev] refactoring petsccusp.h needed >> >> Hi Chetan, >> >> thanks for the patch. Looks good overall, just two more comments: >> >> * defining CUSPARRAY in a public header file is rude, as it is likely to >> interfere with user code. You should at least namespace it, or omit it >> for the prototypes completely. >> >> * The comment in the file header is >> "This should only be included in user code that uses CUSP directly and >> hence the file name ends with .cu" >> However, the file name is petsccusp.h... >> >> Please send me an updated patch and I'll commit the changes. >> >> @Barry: I think it's better to keep petsccusp.h as a separate file, >> otherwise you would have to include-guard <cusp/array1d.h> in petscvec.h >> >> Best regards, >> Karli >> >> >> >> On 03/19/2013 02:57 PM, Chetan Jhurani wrote: >>> Hi Barry / others, >>> >>> Could you look at the attached diff, which avoids >>> exposing private functionality through the petsccusp >>> header? >>> >>> It now exposes stuff relevant to VecCUSP* API calls >>> only and requires changes to these files. >>> >>> include/petsccusp.h >>> src/snes/examples/tutorials/ex47cu.cu >>> src/vec/vec/impls/seq/seqcusp/cuspvecimpl.h >>> src/vec/vec/impls/seq/seqcusp/veccusp.cu >>> >>> Paul is on travel. Hence I am working on this. >>> Let me know if there are any issues. >>> >>> Chetan >>> >>>> -----Original Message----- >>>> From: petsc-dev-bounces at mcs.anl.gov [mailto:petsc-dev-bounces at >>>> mcs.anl.gov] On Behalf Of Paul >> Mullowney >>>> Sent: Friday, March 15, 2013 3:43 PM >>>> To: Barry Smith >>>> Cc: For users of the development version of PETSc >>>> Subject: Re: [petsc-dev] refactoring petsccusp.h needed >>>> >>>> Barry, >>>> >>>> Is March 21 still the target release date? I will look into this asap if >>>> that's the case but I've been trying to fix some other PETSc GPU >>>> problems in GMRES and BCGS algorithms. >>>> >>>> For GMRES, the current performance of VecMDot_SeqCUSP sucks. I have an >>>> solution, but I haven't tested all cases yet. >>>> For BCGS, some part of the algorithm is broken but I don't know what it >>>> is. By broken, I mean that CPU and GPU residuals diverge fairly quickly. >>>> >>>> -Paul >>>>> Paul, >>>>> >>>>> We are thinking of a PETSc release around March 21. Before that >>>>> time petsccusp.h >>>>> >>>>> #if !defined(__PETSCCUSP_H) >>>>> #define __PETSCCUSP_H >>>>> /* >>>>> This should only be included in user code that uses CUSP directly >>>>> and hence the file name >> ends >>>> with .cu >>>>> */ >>>>> #include<../src/vec/vec/impls/dvecimpl.h> >>>>> #include<../src/vec/vec/impls/seq/seqcusp/cuspvecimpl.h> >>>>> #endif >>>>> >>>>> so that ONLY the public interface of the stuff (what needs to be known to >>>>> user code) is available >>>> and the rest is kept in the cuspvecimpl.h file. Maybe pets ccusp.h could >>>> be empty, I don't know). >>>>> >>>>> Do you think you can make that change and anything else that needs >>>>> doing before the release? >>>>> >>>>> Thanks >>>>> Barry >>>>>
