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

[Feature Req] Faster Interpolation #48

Open
steven-murray opened this issue Mar 18, 2022 · 0 comments
Open

[Feature Req] Faster Interpolation #48

steven-murray opened this issue Mar 18, 2022 · 0 comments
Assignees

Comments

@steven-murray
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Speed.

The dominant bottleneck (by a large margin) is the beam interpolation, so anything we can do to shave off time there is a good idea.
Currently if using the pyuvbeam interp (which is the preferred method), it does frequency interpolation as well -- which does short-circuit because the the desired frequency is always in the inherent frequencies (due to a previous interpolation, see #46). However, even short-circuited, it seems to take more time than it perhaps should. This is based on a run I did with 30 time-steps in which the beam already had the desired frequency (so even the pre-interp of frequency was short-circuited). It found that the (short-circuited) freq-interp step took ~4% of the total time. This seems to indicate that the short-circuited freq-interp is taking almost as long as the angular interp. If this is true, then we could perhaps halve the angular interp time by not doing any frequency interp at all (even short circuited).

Ultimately, this is probably something to implement on UVBeam (calling in @mkolopanis), but we could also use a hack to get around it in vis_cpu.

Describe the solution you'd like
I think UVBeam should have a freq_interp method and an angular_interp method that each just focus on their respective domains. If the interp() method is to remain, it could just call each of those in turn, but "power-users" should be able to call the more focused methods.

Describe alternatives you've considered
We could directly use the stored interpolation functions inside the UVBeam object in vis_cpu, which would mean we don't have to do any checks or anything. But, this is using "private" attributes and so shouldn't be considered stable.

Additional context
Since beam interpolation is THE bottleneck step for most realistic simulations, I think UVBeam should work hard to make it as quick as possible.

@steven-murray steven-murray self-assigned this Mar 18, 2022
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

No branches or pull requests

1 participant