feat(beam): use GridBeam in telescope coordinates#238
Conversation
Allows the user to generate a HybridVisStream from a GridBeam in telescope coordinates. This avoids problems at the pole when using GridBeams in celestial coordinates that do not span 360 degrees in hour angle.
|
I have tested the code in a notebook, but have not yet attempted to submit jobs that use this task or examine the results in detail. The updated task should give the same results if provided a GridBeam in celestial coordinates. However, it was restructured a fair amount, so it's possible there will be some unintended changes. We should confirm that we still get the same result for this case. |
tristpinsm
left a comment
tristpinsm
left a comment
There was a problem hiding this comment.
Looks good! I will remake my plots with this code and post the result here.
|
Here are plots generated using the telescope beam input to I generated these in a notebook, but I also submitted a job to make maps using the celestial beam as before. Once this is done I can compare to the maps generated from the old code to see if there is a difference. |
|
Thanks @tristpinsm. I think the remaining ringing in declination is due to the |hour angle| < 90 degree limit that is placed to ignore the antipodal transit. There is roughly +/- 2.5 degrees around the NCP where the beam response is significant at 90 degrees. I'm not sure there are any great options as that assumptions that are made in the beam generation begin to break down as you approach the NCP. Perhaps we should just set the weight dataset for the beam stream to zero for these declinations? |
Yeah that seems reasonable, there is not much sky area there anyway... |
| # Create output container | ||
| out = containers.HybridVisStream( | ||
| ra=nra, | ||
| ra=ra, |
There was a problem hiding this comment.
In the celestial beam case, ra is defined based on the phi axis of the beam container, which doesn't span the full RA range and causes a crash later on. I will fix this and set the test job running again.
| ra = (ha + 360.0) % 360.0 | ||
| nra = int(round(360.0 / np.abs(ha[1] - ha[0]))) | ||
| delta_ra = 360.0 / nra |
There was a problem hiding this comment.
| ra = (ha + 360.0) % 360.0 | |
| nra = int(round(360.0 / np.abs(ha[1] - ha[0]))) | |
| delta_ra = 360.0 / nra | |
| ra_beam = (ha + 360.0) % 360.0 | |
| nra = int(round(360.0 / np.abs(ha[1] - ha[0]))) | |
| delta_ra = 360.0 / nra | |
| ra = np.arange(nra) * delta_ra |
With this change (and propagating ra_beam in the next few lines) the code ran to completion and I confirmed that the result is the same as with the previous version by comparing the ringmap and weights for about 20 unflagged randomly selected frequencies in the lower band.
|
@Arnab-half-blood-prince This PR enables |
|
|
Older versions of scipy do not support use of RectBivariateSpline interpolation on complex numbers. Perform real and imaginary interpolation separately.
2 participants
Allows the user to generate a HybridVisStream from a GridBeam in telescope coordinates. This avoids problems at the pole when using GridBeams in celestial coordinates that do not span 360 degrees in hour angle.