-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat(beam): use GridBeam in telescope coordinates #238
base: master
Are you sure you want to change the base?
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I will remake my plots with this code and post the result here.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
draco/analysis/beam.py
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.