Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issues with == in tests and update to work with numpy 1.25 #917

Merged
merged 3 commits into from
Jun 22, 2023

Conversation

majosm
Copy link
Collaborator

@majosm majosm commented Jun 22, 2023

We seem to have some bugs in our tests that were uncovered by the changes in object array behavior in numpy 1.25. Specifically, in a few places we assert on the equality of ConservedVars objects:

            assert ff_bndry_state.cv == exp_ff_cv

which looks reasonable enough, but upon inspection:

ff_bndry_state.cv == exp_ff_cv=ConservedVars(mass=DOFArray((cl.TaggableCLArray([[1],
       [1]], dtype=int8),)), energy=DOFArray((cl.TaggableCLArray([[1],
       [1]], dtype=int8),)), momentum=False, species_mass=array([], dtype=bool))
bool(ff_bndry_state.cv == exp_ff_cv)=True

i.e., == here is doing some strange things, and CV's boolean conversion is questionable. The discretization here is the boundary of a 1D mesh, so it looks like most of the components are doing elementwise equality, except for momentum.

If I understand correctly, ConservedVars gets its __eq__ operator from arraycontext's with_container_arithmetic decorator. @inducer Is the equality operator resulting from this decorator intended to do elementwise comparison? If so, is there a way we can make it work for array containers containing object arrays? Or do we just need to disable == for ConservedVars, as I've attempted to do here?

Questions for the review:

  • Is the scope and purpose of the PR clear?
    • The PR should have a description.
    • The PR should have a guide if needed (e.g., an ordering).
  • Is every top-level method and class documented? Are things that should be documented actually so?
  • Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
  • Does the implementation do what the docstring claims?
  • Is everything that is implemented covered by tests?
  • Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

@inducer
Copy link
Contributor

inducer commented Jun 22, 2023

This is related, and I think the upshot is that == for array containers with object arrays is no longer a thing, with actx.np.equal(..., ...) the most plausible replacement.

@majosm majosm merged commit 82fac8c into illinois-ceesd:main Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants