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.
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
UVBeamshould have afreq_interpmethod and anangular_interpmethod that each just focus on their respective domains. If theinterp()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
UVBeamobject 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.