[petsc-dev] better regular testing on accelerators

[Scott Kruger]

I think trying to push the logic of the type 'requires: cuda' or 
'requires: !cuda' to be implicit rather than explicit is a bad
if it comes to that.

Scott


On 6/12/19 9:03 AM, Smith, Barry F. via petsc-dev wrote:
> 
> 
>> On Jun 12, 2019, at 9:58 AM, Jed Brown <jed at jedbrown.org> wrote:
>>
>> Would it be sufficient to add the CUDA arguments to PETSC_OPTIONS when running the test suite on those machines?
> 
>    You mean -vec_type cuda -mat_type cuda -dm_vec_type cuda -dm_mat_type cuda ? We should definitely try it, it may break something we'll see. It will miss all the code that uses directly MatCreateAIJ....() but then maybe we should change that code :-)
> 
> 
>    Barry
> 
>>
>> "Smith, Barry F. via petsc-dev" <petsc-dev at mcs.anl.gov> writes:
>>
>>>    In order to get better testing on the accelerators I think we need to abandon the -vec_type cuda approach scattered through a handful of examples and instead test ALL examples that are feasible automatically with the various accelerator options.  I think essentially any examples that use AIJ are feasible for testing (those that use BAIJ, SBAIJ, Ell are not) I am not sure if there is an automatic way to determine all of these cases. Labeling all such test cases manually would likely miss some and be out of date immediately.
>>>
>>>    Any thoughts?
>>>
>>>    Thanks
>>>
>>>    Barry
>>>
>>> Maybe we could short circuit the issue by having a mode of configuring or compiling or running where MatCreate_AIJ and VecCreate_ are bypassed directly to the accelerator cousins (this is not completely trivial because the cousins generally construct the basic ones and then convert themselves to the cousin).
> 

-- 
Tech-X Corporation               kruger at txcorp.com
5621 Arapahoe Ave, Suite A       Phone: (720) 974-1841
Boulder, CO 80303                Fax:   (303) 448-7756