Use arraycontext instead of pyopencl

[alexfikl]

Inspired by inducer/arraycontext#111, this tried to remove some of the direct usage of pyopencl. It's still a far shot from actually working with TaggedCLArray transparently, but it's a start! This mostly removes uses of

• cl.array parts which are in arraycontext
• ary.with_queue(queue) with actx.thaw or actx.freeze
• ary.get() with actx.from_numpy

A few obvious places where pyopencl is still used:

• some calls to cl.wait_for_events; not sure how necessary this is?
• some calls to pyopencl.algoritm: copy_if
• some calls to pyopencl.array: take.
• some kernels: ElementwiseKernel, GenericScanKernel

The main roadblock however seems to be that all the sumpy calls return bare cl.array.Array and generally don't know anything about array contexts.

[inducer]

It's still a far shot from actually working, but it's a start!

What do you mean? CI seems to be passing...

[alexfikl]

It's still a far shot from actually working, but it's a start!

What do you mean? CI seems to be passing...

Ah, I meant from working seamlessly with that TaggedCLArray thing from inducer/arraycontext#111. Well, the version of the PR that only had self.array_types = (TaggedCLArray,) (might have made this PR before I noticed @kaushikcfd fixed things in there).

[inducer]

take

It should be possible to replace at least that with fancy indexing.

[alexfikl]

It should be possible to replace at least that with fancy indexing.

I actually went the other way and left everything in qbx.cost and qbx.fmm (where take was used) alone for now. That's talking to boxtree and sumpy that only know about queues, so it's very awkward to insert an array context in there at the moment.

[alexfikl]

This seems to be introducing some synchronization issues. Most of the functions in QBXFMMGeometryData were creating their own queues to precompute data and this PR switched them to using the array context from the constructor and freezing the results.

Not sure why that would cause issues (it doesn't seem like anything is returned thawed), but it does 😖

[alexfikl]

After some playing around with this: it was only causing failures when using fmmlib where it was using a

with cl.CommandQueue() as queue:
	geo_data = ToHostTransferredGeoDataWrapper(queue, geo_data)

Switching that to using the array context inside geo_data seems to fix any failures. It still seems like something is a bit brittle though :(

[inducer]

This was kind of painful to review, but I finally made it through. LGTM, thanks for working on it!

[alexfikl]

This was kind of painful to review, but I finally made it through. LGTM, thanks for working on it!

Sorry about that! Hopefully it will save some future pain with the array contexts :(