search

Smithsonian / sma2casa

Code to convert SMA data files into FITS-IDI files suitable for importing to CASA
3 stars 6 forks source link

Output MS file has wrong labeling of channel frequencies #3

Open vilhelmp opened 6 years ago

vilhelmp commented 6 years ago

When displaying (plotms) the resulting MS file from the import, the frequencies are shifted 1/2 a SWARM chunk (i.e. ~1.8 GHz). Seems like it is the labeling, since SMA uses the frequency of the center channel and CASA/MS labels the frequency of the first channel (?). Plotting the spectra in IDL/MIR shows the correct spectra. Is this real or is there something I am missing when plotting the MS file in CASA?

vilhelmp commented 6 years ago

I looked into this more. Around line ~820 in sma2casa.py, where the lowestFSky is calculated, there are two things that seems wrong to me.

The first if-statement checking if it is a ASIC (and not Hybrid/SWARM-only) window does not work for SWARM only data. That is the line (and any other line) with if band < 49: should probably be replace with if band < 49 and len(bandList)>5:. This now means for a setup with SWARM only and len(bandList) equalling 5 (4 line + 1 continuum per side band), it comes to the last else: statement in that sequence.

Second, at this statement it uses the spSmallDict data structure to calculate the lowestFSky for each window like this:

else:
    if sb == 0:
        lowestFSky = spSmallDict[band][2] - spSmallDict[band][1]*0.5 - spSmallDict[band][1]*spSmallDict[band][0]*0.5
    else:
        lowestFSky = spSmallDict[band][2] + spSmallDict[band][1]*0.5 + spSmallDict[band][1]*spSmallDict[band][0]*0.5

Looking at the spSmallDict structure

In [6]: spSmallDict
Out[6]: 
{0: (1, 558593.75, 206515099153.24918, 203400000000.0),
 1: (4096, -558593.75, 209520824411.18948, 203400000000.0),
 2: (4096, 558593.75, 207508894235.40823, 203400000000.0),
 3: (4096, -558593.75, 205520894235.40823, 203400000000.0),
 4: (4096, 558593.75, 203508894235.40823, 203400000000.0)}

for band=0 in my data, the spSmallDIct[0][1] value (i.e. frequency resolution) is either negative or positive. This means lowestFSky will either go up or down depending on that sign. As far as I can see, this is wrong? A fix to this seems to be:

 else:
      if sb == 0: # Lower Sideband
           lowestFSky = spSmallDict[band][2] - abs(spSmallDict[band][1])*0.5 *(1+spSmallDict[band][0])
      else: # Upper Sideband
           lowestFSky = spSmallDict[band][2] - abs(spSmallDict[band][1])*0.5 *(1 + spSmallDict[band][0])

As you can see these are now identical and no check for sideband would be needed, but perhaps good to leave it there for future possible uses. I tried this, but I have no strong sure line (i.e. CO) to compare to, but it seems to generate the correct frequency coverage.