[petsc-dev] why does veccuda.py exist?

[Smith, Barry F.]

> On Feb 2, 2018, at 11:10 PM, Karl Rupp <rupp at iue.tuwien.ac.at> wrote:
> 
> Hey,
> 
>>    I'm am totally confused by
>> 1) the existence of veccuda.py
> 
> if I remember correctly, its purpose is to make sure that one of the GPU backends is enabled if a user configures --with-cuda.
> 
> 
>> 2) the fact that veccuda.py depends on some packages but is not a package and is not in packages/
> 
> I don't know this. In any case, veccuda.py is an artifact of a too rigid GPU backend implementation and should be removed once the GPU backend implementation is fixed.
> 
> 
>> Why can't the VECCUDA type coexist with the VECCUSP or VECVIENNACL types? If it can't coexist, can the code be reworked to allow it to coexist?
> 
> Currently it can't coexist because some variables are conditionally compiled and may be multiply defined (e.g. spptr).

  Hmm, I don't think so. The use of spprt shouldn't mean there cannot be both VECCUDA and VECCUSP at the same time (with different vectors obviously).

> 
> 
>> Can we get rid of the veccuda.py and the PETSC_HAVE_VECCUDA flag and just always have the VECCUDA type if cuda is available?
> 
> Yes, that's possible after some refactorization.
> 
> 
>> I'm willing to do the refactorization and simplification but I need to know there is not some secret reason for these complications.
> 
> Unless you have to deliver something specific within the next few days, I'll (finally!) do it next week together with getting rid of VECCUSP.

   So are we giving up on CUSP? And just using CUDA directly and ViennaCL?

> These two steps should be done concurrently to avoid needless work.

   There is no hurry; except I hate ugliness hanging around once I see it ;( It makes my skin itch, just knowing it exists ;)


> 
> Best regards,
> Karli