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

Return device scalars from nodal_sum/nodal_min/nodal_max #170

Merged
merged 15 commits into from
Oct 28, 2021

Conversation

majosm
Copy link
Collaborator

@majosm majosm commented Sep 24, 2021

Closes #168.

⚠️ Merge together with illinois-ceesd/mirgecom#518. ⚠️

@majosm majosm force-pushed the nodal-reduction-device-scalar branch from fb65e9c to 8b00650 Compare September 24, 2021 20:24
@majosm majosm force-pushed the nodal-reduction-device-scalar branch 2 times, most recently from 2609903 to 7a1b391 Compare October 13, 2021 19:31
@majosm majosm force-pushed the nodal-reduction-device-scalar branch 2 times, most recently from 6902796 to e5f8d9d Compare October 19, 2021 14:32
@majosm majosm force-pushed the nodal-reduction-device-scalar branch from e5f8d9d to ea69dec Compare October 19, 2021 14:33
@majosm majosm marked this pull request as ready for review October 20, 2021 14:33
thomasgibson
thomasgibson previously approved these changes Oct 20, 2021
Copy link
Collaborator

@thomasgibson thomasgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this @majosm --- I saw no major issues after scanning through this PR. How should we proceed forward with respect to illinois-ceesd/mirgecom#518? Probably merge this first, followed immediately with the mirgecom PR? If so, let's coordinate so we can time this right.

@majosm
Copy link
Collaborator Author

majosm commented Oct 20, 2021

Thanks for doing this @majosm --- I saw no major issues after scanning through this PR. How should we proceed forward with respect to illinois-ceesd/mirgecom#518? Probably merge this first, followed immediately with the mirgecom PR? If so, let's coordinate so we can time this right.

Yeah, I think we would merge this, then remove the requirements.txt change in illinois-ceesd/mirgecom#518, run its CI once more, and then merge it. Afterwards we can revert the ci.yml change from this PR. Do I have this right @inducer?

Copy link
Collaborator

@alexfikl alexfikl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple of comments for some things I'm not quite sure about, but overall 👍!

I haven't been keeping up with grudge and maybe some of them aren't relevant, so feel free to ignore as needed!

grudge/dt_utils.py Outdated Show resolved Hide resolved
grudge/reductions.py Show resolved Hide resolved
grudge/reductions.py Outdated Show resolved Hide resolved
grudge/reductions.py Outdated Show resolved Hide resolved
@thomasgibson thomasgibson self-requested a review October 20, 2021 15:53
Copy link
Collaborator

@thomasgibson thomasgibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @majosm but I sort of had a change of heart with regard to type annotations using Any

@@ -158,7 +159,7 @@ def dt_non_geometric_factors(

@memoize_on_first_arg
def h_max_from_volume(
dcoll: DiscretizationCollection, dim=None, dd=None) -> float:
dcoll: DiscretizationCollection, dim=None, dd=None) -> Any:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I feel like type annotating with Any is not very helpful. In fact, I feel it just sorta raises more questions. I'd rather just remove the return annotation (at least for h_max and h_min here).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe try a DeviceScalar = Any type alias?

https://www.python.org/dev/peps/pep-0484/#type-aliases

Mypy shouldn't be bothered, but I don't know if it'll render nicely in Sphinx.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should be able to trick sphinx into it too using autodoc_type_aliases.

That seems to require from __future__ import annotations, which is a >=3.7 thing, so probably needs to be hidden behind an if BUILDING_DOCS or something?

Copy link
Owner

@inducer inducer Oct 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from __future__ import annotations should be unnecessary if you make the annotation a string. (I think)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using the ArrayT type hint from arraycontext? Something like: majosm@0e1be13?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the point of view of the type checker, they're probably interchangable here. Using a single unbound TypeVar in a function definition doesn't actually constrain anything, you need something like

def function(x: T) -> Sequence[T]: ...

i.e. it should tie in more than one input + output, for it to do something. (at least that's my understanding of it)

Since this is mostly for documentation at this point, either one is fine from my point of view (at least can't think of any particular downside?)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the DeviceScalar thing directly in arraycontext in inducer/arraycontext#117, since other code may want to use it too.

Without from __future__ import annotations, sphinx seems to be quite limited about where it allows type aliases, but pylint and mypy work as expected.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I doing this right? (e8fd358)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 It seems to be rendering just fine on my machine too.

grudge/reductions.py Outdated Show resolved Hide resolved
grudge/reductions.py Outdated Show resolved Hide resolved
@majosm majosm force-pushed the nodal-reduction-device-scalar branch from 1778902 to 214e865 Compare October 20, 2021 20:57
Copy link
Owner

@inducer inducer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@@ -158,7 +159,7 @@ def dt_non_geometric_factors(

@memoize_on_first_arg
def h_max_from_volume(
dcoll: DiscretizationCollection, dim=None, dd=None) -> float:
dcoll: DiscretizationCollection, dim=None, dd=None) -> Any:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe try a DeviceScalar = Any type alias?

https://www.python.org/dev/peps/pep-0484/#type-aliases

Mypy shouldn't be bothered, but I don't know if it'll render nicely in Sphinx.

grudge/models/__init__.py Outdated Show resolved Hide resolved
@majosm majosm force-pushed the nodal-reduction-device-scalar branch from ed86d15 to a9477fe Compare October 25, 2021 21:18
@majosm majosm force-pushed the nodal-reduction-device-scalar branch from a9477fe to a2c54f0 Compare October 25, 2021 22:39
@majosm majosm requested a review from inducer October 28, 2021 17:21
@majosm
Copy link
Collaborator Author

majosm commented Oct 28, 2021

(Looks like I don't have merge permissions for grudge.)

@thomasgibson thomasgibson merged commit a788ad6 into inducer:main Oct 28, 2021
@inducer
Copy link
Owner

inducer commented Oct 29, 2021

(Looks like I don't have merge permissions for grudge.)

Added you.

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.

Reductions return a device scalar without MPI and a host scalar with MPI
4 participants