While working on #1695, I stumbled upon an interesting feature of the MIRIAD reader, which is that the antenna numbers start with zero. Ant 0 is sort of a kludgy thing within MIRIAD because of the mixture of C and Fortran in the code (which are 0- and 1-indexed, respectively), and I was surprised that when reading in an SMA dataset, the antenna numbers were coming out to be 0->7 (when within MIRIAD they are numbered 1->8, matching where they appear elsewhere). Looking around, I stumbled upon this block of code in miriad_wrap.pyx:
cdef inline int GETI(int bl):
return (bl - 65536) // 2048 - 1 if bl > 65536 else (bl >> 8) - 1
cdef inline int GETJ(int bl):
return (bl - 65536) % 2048 - 1 if bl > 65536 else (bl & 255) - 1
cdef inline float MKBL(int i, int j):
return (i + 1) << 8 | (j + 1) if (i + 1 < 256 and j + 1 < 256) else (i + 1) * 2048 + (j + 1 + 65536)
That's being called later when the preamble is being unpacked, which maps antennas to a given baseline:
i = GETI(<int>preamble[4])
j = GETJ(<int>preamble[4])
return (uvw, preamble[3], (i, j)), data, flags, nread
Strictly speaking, this isn't "wrong", but rather a convention choice. But, it does mean that the numbering in MIRIAD is different than how it appears in other datasets, including those that MIRIAD is capable of generating itself (e.g., via the fits function to output UVFITS format). For my specific use case (reading in old MIRIAD gains to match to directly-read MIR files read via MirParser), I can kludge a fix, but it strikes me that it may be worth considering a fix/change that would affect both the UVData and UVCal based classes. Within #1695 I've left the numbering as-is so as to maintain consistency, and I think this is worth fixing, but I know that part of pyuvdata's heritage w/ MIRIAD runs through PAPER, and I don't know if this has the potential to break something that we'd prefer be left alone.
While working on #1695, I stumbled upon an interesting feature of the MIRIAD reader, which is that the antenna numbers start with zero. Ant 0 is sort of a kludgy thing within MIRIAD because of the mixture of C and Fortran in the code (which are 0- and 1-indexed, respectively), and I was surprised that when reading in an SMA dataset, the antenna numbers were coming out to be 0->7 (when within MIRIAD they are numbered 1->8, matching where they appear elsewhere). Looking around, I stumbled upon this block of code in
miriad_wrap.pyx:That's being called later when the preamble is being unpacked, which maps antennas to a given baseline:
Strictly speaking, this isn't "wrong", but rather a convention choice. But, it does mean that the numbering in MIRIAD is different than how it appears in other datasets, including those that MIRIAD is capable of generating itself (e.g., via the
fitsfunction to output UVFITS format). For my specific use case (reading in old MIRIAD gains to match to directly-read MIR files read via MirParser), I can kludge a fix, but it strikes me that it may be worth considering a fix/change that would affect both the UVData and UVCal based classes. Within #1695 I've left the numbering as-is so as to maintain consistency, and I think this is worth fixing, but I know that part of pyuvdata's heritage w/ MIRIAD runs through PAPER, and I don't know if this has the potential to break something that we'd prefer be left alone.