-
Notifications
You must be signed in to change notification settings - Fork 11
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
PytatoArrayContext.freeze: support container freezes #158
Conversation
arraycontext/container/traversal.py
Outdated
@@ -533,6 +533,9 @@ def freeze( | |||
|
|||
See :meth:`ArrayContext.thaw`. | |||
""" | |||
if actx is not None and actx.supports_freezing_containers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should just deprecate these then (and expect all array contexts to support container freezes).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the freeze logic is specific to the containers (freeze is a single-dispatch function), deprecating this won't be possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also be added to meshmode.dof_array then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a side note, I really don't recall why we made this singledispatch
-ed and can't think of a reason for it now. Anyone remember something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't. Array container freeze seems completely generic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't recall why we made this singledispatch-ed and can't think of a reason for it now. Anyone remember something?
IIUC, array container initialization might be specific to the container type, and instead of forcing any constructor API we ask the container's writer to also provide a freeze. For example, DOFArray takes in a .array_context
argument during initialization that must be set to None
on getting frozen.
This should also be added to meshmode.dof_array then?
Yep!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, array container initialization might be specific to the container type, and instead of forcing any constructor API we ask the container's writer to also provide a freeze. For example, DOFArray takes in a
.array_context
argument during initialization that must be set toNone
on getting frozen.
And using deserialize_container
doesn't work because the template arg isn't necessarily frozen. Hm.. annoying..
Thanks for the reminder!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revisiting this: given the new logic, I think we ought to just deprecate the stand-alone freeze
in favor of actx.freeze
. (same for thaw
) I don't see a strong rationale for keeping them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do make it easy to just call freeze(container)
as the actx
is automatically inferred, if possible. If this is something that seems unnecessary, happy to deprecate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9877625
to
a2d3deb
Compare
Discussed with @alexfikl a bit regarding the issue of how to set So the second-best solution we came up with is to deprecate How does that sound? |
a430a74
to
1bcd6c4
Compare
Yep, this sounds like a cleaner approach. I've implemented the suggestions, however back-compatibility seems challenging (unachievable?). For ex. meshmode needs inducer/meshmode#327. |
Yep, that's understood. But IMO |
1bcd6c4
to
2cb8d04
Compare
70d61a2
to
7bef0f6
Compare
20b54ce
to
7db55ca
Compare
7db55ca
to
d373c46
Compare
arraycontext/container/traversal.py
Outdated
@@ -533,6 +533,9 @@ def freeze( | |||
|
|||
See :meth:`ArrayContext.thaw`. | |||
""" | |||
if actx is not None and actx.supports_freezing_containers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revisiting this: given the new logic, I think we ought to just deprecate the stand-alone freeze
in favor of actx.freeze
. (same for thaw
) I don't see a strong rationale for keeping them.
d373c46
to
cbd3ade
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! A few things to do here, but hopefully nothing onerous or disruptive. LGTM once these are take care of.
arraycontext/container/traversal.py
Outdated
@@ -533,6 +533,9 @@ def freeze( | |||
|
|||
See :meth:`ArrayContext.thaw`. | |||
""" | |||
if actx is not None and actx.supports_freezing_containers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…ArrayContext.freeze` Co-authored-by: Andreas Kloeckner <[email protected]>
cbd3ade
to
39b7cc7
Compare
LGTM, thanks! Force-merging based on success of previous CI. |
Freezing across containers can potentially re-use common sub-expressions.
with_array_context
for DOFArrays meshmode#327.Draft because: