RadioAstronomySoftwareGroup / RadioAstronomySoftwareGroup/pyuvdata

MIRIAD numbering convention inconsistency

Open
#1,700 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
102
Forks
35
Avg merge
1d 20h
Merged PRs (30d)
14

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with miriad_wrap.pyx, especially GETI, GETJ, MKBL, and the preamble-unpacking call site. Trace how these values reach the UVData and UVCal classes and compare their numbering with MIRIAD-generated UVFITS and MirParser inputs. Done means the convention is consistently defined across the affected classes without breaking established MIRIAD behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.