I'm not sure this has any business being here, but I didn't have the stamina to give meshmode its own PyOpenCLArrayContext subclass again. Nonetheless, I think that's what we should do. @matthiasdiener, I'd be grateful for your help here.
That means:
updating those imports across the tests and examples (in meshmode), and
making the pytest fixture customizable as to what actx classes to use,
Same goes for grudge and mirgecom, as they will likely grow their own kernel metadata at some point.
This also makes the other transform strategies redundant, so those can really go. (and the other meshmode kernels should be updated to use this one)
So PyOpenCLArrayContext.transform_loopy here should really just raise. To still be able to run tests for this package, introduce a subclass that has a no-op transform_loopy.
To avoid a huge performance pitfall, it's important that the array context provides a useful error if no applicable transform strategy was found.
This is intended to help revive https://github.com/inducer/meshmode/pull/217. It's used in https://github.com/inducer/meshmode/pull/220.
I'm not sure this has any business being here, but I didn't have the stamina to give meshmode its own
PyOpenCLArrayContext
subclass again. Nonetheless, I think that's what we should do. @matthiasdiener, I'd be grateful for your help here.That means:
PyOpenCLArrayContext.transform_loopy
here should really just raise. To still be able to run tests for this package, introduce a subclass that has a no-optransform_loopy
.Draft because:
requirements.txt
back tomain
cc @thomasgibson @alexfikl