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 <[email protected]> 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" <[email protected]> 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 [email protected]
5621 Arapahoe Ave, Suite A Phone: (720) 974-1841
Boulder, CO 80303 Fax: (303) 448-7756
