DeprecationWarning when broadcasting scalar array type over DOFArray #292
Description
As discussed from CS meeting earlier, I am getting a DeprecationWarning when dividing a DOFArray by an arraycontext scalar:
/Users/nnytko2/Git/ceesd-nonlinear-solve/code/actx_issue.py:17: DeprecationWarning: Broadcasting <class 'meshmode.dof_array.DOFArray'> over array context array type <class 'arraycontext.impl.pyopencl.taggable_cl_array.TaggableCLArray'> is deprecated and will no longer work in 2025. There is no replacement as of right now. See the discussion in https://github.com/inducer/arraycontext/pull/190.
y = x / flat_norm(x) # Warning occurs here
And minimal reproducing example:
import numpy as np
import pyopencl as cl
from grudge.discretization import make_discretization_collection
from meshmode.array_context import PyOpenCLArrayContext
from meshmode.mesh.generation import generate_box_mesh
from meshmode.dof_array import flat_norm
from pytools.obj_array import flat_obj_array
ctx = cl.create_some_context()
queue = cl.CommandQueue(ctx)
actx = PyOpenCLArrayContext(queue)
mesh = generate_box_mesh((np.linspace(0, 1, 10),))
dcoll = make_discretization_collection(actx, mesh, order=1)
x = dcoll.zeros(actx) + 1.
y = x / flat_norm(x) # Warning occurs here
Activity
inducer commentedon Dec 11, 2024
Thanks for writing this up! This is an informative corner case. We started issuing a warning for this type of code because finding the array types associated with an array context (to allow broadcasting specifically for them) has a number of problems:
At the same time, broadcasting device scalars is (IMO) eminently reasonable, and I feel that the above code should probably be allowed.
So this comes down to the question of whether we should create a loophole for "scalars". A dumb-and-perhaps-not-too-expensive way to detect them would be
getattr(ary, "shape", None) == (). But this feels loosey-goosey in a not-so-healthy way. I'd be grateful for alternate proposals/ideas.cc @alexfikl
inducer commentedon Dec 11, 2024
#280 barks up a similar tree, but it's still not a great solution.
alexfikl commentedon Dec 11, 2024
I don't really have any new useful ideas :( At least at the time this warning was introduced, what I mostly had in mind was written here: #190 (comment).
In general, it seems like the hard part is
ContainerTypeA + ContainerTypeB, where we don't know who's supposed to broadcast into who. MakingContainerTypeA + ArrayOrScalarwork should be doable with some hackery (like you mentioned)..