Drop support for eager PyOpenCL

[inducer]

There's so much junk code in grudge that accommodates PyOpenCL's inability to broadcast properly, and I'm kind of over it. Numpy still works for eager debugging, so this shouldn't be a big loss. Any objections?

Depends on:

• add NumpyArrayContext arraycontext#235 (to preserve eager test mode)

cc @alexfikl @matthiasdiener @majosm @MTCam @anderson2981 @lukeolson

[matthiasdiener]

No objection, but noting that the numpy support isn't available in the main branches yet, i.e.:

• add NumpyArrayContext arraycontext#235
• Add MPINumpyArrayContext #312

[MTCam]

I'm for it. I think mirgecom will be fine. We exercise all the examples with numpy options.

[anderson2981]

Is there any benefit to fixing PyOpenCL to support broadcast properly?

[inducer]

No objection, but noting that the numpy support isn't available in the main branches yet

Great point. I'm hoping to fix that super soon. I've also added inducer/arraycontext#235 as a dependency.

Is there any benefit to fixing PyOpenCL to support broadcast properly?

I don't think so. PyOpenCL's array type is all hand-coded code generators that are fundamentally limited to 1D. Generalizing them to n dimensions was (part of) the motivation for starting loopy. A loopy-using eager array type could be built, but

• it would involve scrapping most of the existing code, and
• it would still be eager, i.e. way too slow for practical use.

I.e. I kind of don't see the point.