Skip to content

Use a default active cells map for kernel launching #4453

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

glwagner
Copy link
Member

Curious about the performance implications of this.

I think it is better to do the same thing re: active cells for every kernel, rather than picking and choosing.

The main advantage is the simplicity of the algorithm.

Ultimately I think that the active cells should be part of the KernelParameters. It doesn't make sense to think of the kernel parameters and active map as separate concepts.

It should be automatically computed for the majority of kernels, and only changed for edge cases. I am not sure why there are edge cases, but it seems they exist for halo filling?

cc @simone-silvestri can you help improve this design? Perhaps we can discuss here.

Ironing out these issues will become crucial if we want to use Oceananigans finite volume engine for implementing additional models. I also think a distributed algo refactor needs to come at some point, and this is perhaps the first step.

@simone-silvestri
Copy link
Collaborator

simone-silvestri commented Apr 29, 2025

Make sense to have it as a default. I think the default should depend on the workspec. If the workspec is a default workspec (for example :xyz or :xy) we can point to the correct active map (for example Val(:interior) or Val(:surface), respectively -- maybe we can change the naming to actually be :xyz and :xy instead of Val(:interior) and Val(:surface) so it is more clear -- or nothing in case of :xz and :yz). Also, if the workspec is a KernelParameters, then I would have the default be nothing because it means that we are trying to have ``non-default'' behavior.

Indeed, following these changes, the distributed algorithm needs to change because at the moment is harcoded with maps for interior, east, west, north, and south which would not work with this paradigm.

@glwagner
Copy link
Member Author

Indeed, following these changes, the distributed algorithm needs to change because at the moment is harcoded with maps for interior, east, west, north, and south which would not work with this paradigm.

But this is just the default. Doesn't that mean existing code can stay?

@glwagner
Copy link
Member Author

glwagner commented Apr 29, 2025

What does :surface mean? Is that the top or the bottom? it's ambiguous because for atmospheres, :surface is the bottom. For oceans it usually means top, but for sea ice it can be top or bottom. This ambiguity is why we use the terms "top" and "bottom" rather than "surface" and "bottom".

@glwagner
Copy link
Member Author

What's the point of having different names for things? Can we just use :xyz or :interior --- rather than both?

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.

2 participants