BPLOT is a really cool task

I recently learned about a task in AIPS which is very good for assessing bandpass stability---BPLOT. If you have multiple bandpass solutions, it will plot each one, stacking them one on top of each other as a time sequence. To the left is an example plot from BPLOT. Try it, you'll like it!

Read more!

CVEL bug

I received an email yesterday informing people of a bug in CVEL - that is, if you run CVEL on a data set after SPLIT with an NX table, you are affected! I wanted to post it here in case you're not on the Midnight Job (MNJ) list (which I wasn't). Essentially, CVEL will only shift the first scan to the new velocity axis, while the other scans are not shifted. This bug is explained here. I think the possible fixes are to either run CVEL before SPLIT or to run the midnight job to update your AIPS version and then rerun the new CVEL version on your data.

Read more!

Joining Spectral Line Data with Multiple IFs

Occasionally I've encountered line data that are taken in 4-IF mode - that is, where you have 2 IFs, each tuned to different frequencies, that overlap on their edges. I found these to be a pain to combine the last time I worked with them (in my first Astronomy research project ever!), and they have resurfaced again now.. but I've discovered a much easier solution: UJOIN!

UJOIN takes a data set with 2 IFs tuned to different frequencies (as from 4-IF mode at the VLA), and joined them together. It even deals with re-weighting the overlap regions because now there's more data there! You will want to use UJOIN on data that has already been calibrated (gain AND bandpass).

Here are the inputs:

AIPS 1: UJOIN     Converts IFs to additional spectral channels
AIPS 1: Adverbs     Values                 Comments
AIPS 1: ----------------------------------------------------------------
AIPS 1: INNAME     ' '                     Input UV file name (name)
AIPS 1: INCLASS    ' '                     Input UV file name (class)
AIPS 1: INSEQ         0                    Input UV file name (seq. #)
AIPS 1: INDISK        0                    Input UV file disk unit #
AIPS 1: OUTNAME    ' '                     Output UV file name (name)
AIPS 1: OUTCLASS   ' '                     Output UV file name (class)
AIPS 1: OUTSEQ        0                    Output UV file name (seq. #)
AIPS 1: OUTDISK       1                    Output UV file disk unit #.
AIPS 1: CHANSEL    *all 0                  Begin, end input channels,
AIPS 1:                                    begin output channel each IF
AIPS 1: OPCODE     ' '                     'DIFF' to output the vis
AIPS 1:                                    difference in the overlap
AIPS 1: DOWEIGHT      1                    0 => delete spectrum if any
AIPS 1:                                    IF or channel is flagged
AIPS 1:                                    < -0.5 => keep data even if
AIPS 1:                                    one of the IFs is flagged
AIPS 1:                                    > 0.5 => delete channel if
AIPS 1:                                    one of the IFs is flagged

The main thing to set is CHANSEL. This is a 6-element array:

chansel(1) - first channel to use from IF 1
chansel(2) - last channel to use from IF 1
chansel(3) - output channel that corresponds to 1st input channel from IF 1 (ugh)
chansel(4) - first channel to use from IF 2
chansel(5) - last channel to use from IF 2
chansel(6) - output channel that corresponds to 1st input channel from IF 2 (ugh again)


The AIPS help file on UJOIN has some helpful information on how to set these values properly, but I will reproduce what I did to set these - it's not completely straightforward.

Using UJOIN on your own data
First, you should apply all your calibrations in SPLIT. Make sure that when you SPLIT off your science source, you keep BIF and EIF set to 0 - this will create a single source file with both IFs.

Then, you will need to figure out the frequency and reference pixel of each of your observations (f_1, p_1, f_2, p_2). I did this by SPLITting each IF off separately from the LINE data and then running IMHEAD on each. You should also record delta_f (from IMHEAD again - this should be the same for each IF). In my case, f_2 was bigger than f_1 - if this is different for you, you'll have some sign differences somewhere and CHANSEL will be in a different order.

Next, figure out if any of the channels in your IFs are on the edges of the bandpass. You will not want to keep these channels as they will add noise into the final, combined UV data. Typically, look at the region where the bandpass is flat-ish, and use that. To find these, you will want to use POSSM to take a quick look at your bandpass solutions for each antenna:


default possm
aparm = 0, 1, 0.7, 1.3, -180, 180, 0, 2, 0, 0
source [bpass calibrator]
solint -1
nplots 9
dotv 1
bpver 0


Find the first and last channels of the flat-ish region for each IF (n_first,1; n_last,1; n_first,2; n_last,2).

Now you can start setting CHANSEL with the first and last channels for IF 1:

chansel(1) = n_first,1      # first channel from flat-ish part of bpass, if 1
chansel(2) = n_last,1       # last channel from flat-ish part of bpass, if 1
chansel(3) = 1              # ichansel(1) goes into output channel 1
chansel(4) = n_first,2      # first channel from flat-ish part of bpass, if 2
chansel(5) = n_last,2       # last channel from flat-ish part of bpass, if 2

Now we move on to chansel(6), which is not nearly as easy as the above part was. Here you have to figure out which output channel corresponds to chansel(4). You'll have to take into consideration all the other ichansel values. Here is the equation I came up with for ichansel(6):



You can find the derivation at the end of this post if you're interested or getting incorrect answers. (As Martha Haynes once said, "You get what you pay for and this is free!")



As a reminder, here's what all of the variables stand for:

        n = this is the value for ichansel(6)
    f_1,0 = reference frequency of IF 1
    f_2,0 = reference frequency of IF 2
  delta_f = frequency steps between channels
n_first,1 = first channel of IF 1 used in output
n_first,2 = first channel of IF 2 used in output
      p_1 = reference channel of IF 1
      p_2 = reference channel of IF 2

Testing that UJOIN did the right thing
You'll probably want to check that this actually worked correctly. The UJOIN help recommends that you use POSSM to check that the spectrum of the phase calibrator is flat.

- First, SPLIT off the phase calibrator separately.

- Next, run UJOIN on this phase calibrator file with the same inputs as for the galaxy.

- Check that the spectrum of the UJOIN data is flat in POSSM:

default possm
aparm 0
solint 0
nplots 0
source [phase calibrator]

This should plot the phase calibrator spectrum with data from all antennas averaged together.


My derivation of the ichansel(6) equation:
To figure this out, I wrote some equations to find the frequency at a given channel (f1, f2):



These tell you the frequency (f_1, f_2) at an arbitrary channel (n_1, n_2) for each IF. f_1,0 tells you the frequency at reference pixel p_1 for IF 1. f_2,0 tells you the frequency at reference pixel p_2, for IF 2. delta_f is the frequency steps between each channel.

Now we can write an equation to for the frequency of the output channels:


We can sub in for f_out,0 because we know what channel we're setting as the first output channel (ichansel 1!), and we know its frequency from the above equation for f_1 (n_1) for IF 1:



Now we want to know what output channel (n) corresponds to the first channel of IF 2 (n_first,2). Where does this occur in f_out?




Now just rearrange that for n!

Read more!

Combining VLA Spectral Line Data with Different Channel Spacings: a Solution!

I remember thinking about this briefly in a post further down, and neither Amanda nor I could come to a good solution without resorting to Miriad. After running into the problem myself and spending a lot of time dealing with AIPS, I think I've come to a solution.

Caveat: this is only valid for combining VLA data with other VLA data. I don't think it will work with ATNF/GMRT + VLA data, but I haven't tried.

I managed to fix this problem in the case of VLA data with a combination of UVCOP, SPECR, and CVEL. Basically, it works because the VLA correlator setup is all multiples of two. In general, if you have a data set with twice as many channels, it has half the channel spacing. This is not always true due to an observer's ability to set up IFs in different ways, but the channel spacings should always differ by some power of two.

Now for the solution(s).

For example, imagine you have spectral line data set A with 127 channels and spacing of 6.1 kHz, and data set B with 255 channels and spacing of 3.05 kHz. (The extra channel from each needed to make a power of two is the Channel 0 data set. So you really only have 127 instead of 128 and 255 instead of 256 channels.) Effectively, you will have to either double the channel spacing of data set B, or half the channel size of data set A.

In order to DBCON, you will need to jump through many AIPS hoops in order to make sure that both data sets have:
- the same number of channels
- the same spectral resolution
- the same frequencies assigned to the same channels

To degrade the high-resolution data:
- First, you will need to use UVCOP to chop off one channel in data set B, so an integer number of channels in SPECR will give you the correct velocity resolution. It shouldn't matter if you chop one off from the beginning or from the end, as these are generally line free.

- Next, use SPECR to regrid data set B to the proper channel spacing. In this case, you will want a channel spacing of 6.1 kHz. This means that you need to tell SPECR to regrid to half as many channels. Each new channel has twice the original channel spacing. In this case, you will tell SPECR to use npoints 127, which is conveniently half of 254.

- Now run CVEL on both data sets. The correct inputs are described at the bottom of this guide. The main APARM values to set are:

aparm(1) = [velocity in m/s to be assigned to..]
aparm(2) = [..this channel number]

Essentially, you have regridded both of your data sets to a system where the given velocity is assigned to the given channel. It may spit out a lot of errors saying that it is shifting the channels by many km/s, but as long as the same channels in both data sets correspond to the same velocities, you're set.

- Run UVCOP to chop off additional channels if necessary. In this case, the data sets should be the same, but depending on correlator settings, you may have to chop off additional channels. This time, always chop them off from the end, because you have regridded your data so that the first channels in the set line up with the first channels in the other data set.

- Run DBCON to combine both data sets. DBCON will shift RA and Dec as long as the pointing centers aren't vastly different.

To oversample the low-resolution data:

- Use SPECR to regrid data set A to 254 (NOT 255) channels. This will effectively chop your channel width in half, so it matches data set B. You will deal with the fact that both data sets have a different number of channels in a few steps, so don't worry.

- Use CVEL to assign the same frequency to the same channel for both observations. This will shift each spectrum in frequency/channel, but will not resize the channel spacing. More instructions for using CVEL are at the bottom of the guide. The important inputs are:

aparm(1) = [velocity in m/s to be assigned to..]
aparm(2) = [..this channel number]


Essentially, you have regridded both of your data sets to a system where the given velocity is assigned to the given channel. CVEL may spit out a LOT of errors telling you that you are shifting your channels by a lot, but as long as your galaxy shows up in the same channels in both datasets, you should be okay.

- use UVCOP to chop off additional channels. Data set A (after SPECR) has 1 fewer channel than data set B. Fix this by chopping off the last channel of data set B using UVCOP. Set BCHAN 0 and ECHAN 254.

- Use DBCON to combine data set A (after SPECR + CVEL) and data set B (after CVEL + UVCOP). It should shift the RA and Dec of the one of the data sets unless they have vastly different pointing centers.


Now for something completely different (aka additional notes):

Occasionally you will have to chop off more channels from data set A, depending on your correlator set up for both observations. The key point is to make sure that both data sets have the same number of channels with the same channel spacing and the same velocity definition (e.g., channel 52 = -50 km/s).

And now some info on running CVEL. In some of our observations, we did not use Doppler tracking (Oh, EVLA, you'll be awesome one day), so we also had to tell CVEL the rest frequency of our HI line so it could calculate gas velocity. You may not need all of these inputs, but here's how I had to set the APARM values, which is really the meat of CVEL:

aparm -50000 52 1 0 1.420e09 5752 1 0

What does this mean? Well!


aparm(1) = -50000
aparm(2) = 52


Together these two values shift the spectrum so that a velocity of -50000 m/s lines up with channel 52. This will be different for each galaxy - in our case, it's a galaxy with a systemic velocity of -50000 m/s (NGC 404 in fact).


aparm(3) = 1
aparm(4) = 0


These set the velocity definition. The first sets the reference to heliocentric velocity, and the second tells AIPS to use the optical definition.


aparm(5) = 1.420e09
aparm(6) = 5752


This sets the rest frequency of your line in GHz. AIPS does not have enough precision for all the significant figures, so you have to use two APARM values. If you're working with something other than HI, I recommend reading the help file to figure out how to input your frequency.


aparm(7) = 1


This is set to 1 for VLA data.

Read more!

Measuring Spectral Lines

From reader Fred:

When you've got spectral lines in emission, what's the best way of actually reliably measuring them in AIPS? Half the time, when JMFIT is run on a line, the peak and integrated fluxes come out identical (which makes me suspicious!).

my (small amount of) insight below the fold...

I don't usually measure spectral lines in AIPS, and am much more likely to do it in say, IDL, so I don't have any direct insight for you. I'm guessing that JMFIT is not a good way to measure lines, though. I have used JMFIT a lot for measuring continuum point sources, and I can tell you that when the peak and the integrated flux come out to be about equal, this usually means that the source is unresolved. I'm guessing that your spectral lines aren't all actually unresolved (<1 channel in width?), so perhaps JMFIT just doesn't really know what to do with spectral lines. The problem might be that it expects everything to be in terms of mJy/beam, and it usually knows what the beam is in RA/Dec coordinates, and so it is all set up to fit a gaussian to a source and figure out how many beams it covers and how many mJy it emits. This whole set-up doesn't makes much sense when you are talking about one of the coordinates being mJy/channel...

So, I'm skeptical of using JMFIT, but it might be possible. Unfortunately I don't have other suggestions in AIPS, but I bet other people do?

Read more!

Flip frequency axis in UV data?

Hey, does anyone know an equivalent of 'TRANS' in the UV domain? I have two datasets that I need to DBCON, but they are in reverse order (i.e. CDELT > 0 for one, and CDELT < 0 for the other). Is there a task to flip the UV sideband?

Read more!

FreqID tolerance

And another question from reader Korinne:

With data all observed looking for a particular spectral line over a few objects, should you use different frequency ids for the objects or can you use the same frequency id? I've been using a suggested value of a 2 MHz frequency tolerance in the manual which means they all end up with the same frequency id, but I do not know if it's right.

Thoughts?

Read more!

Combining Spectral Line UV Data (with slightly different channel setups)

Update: See this lovely post by Adrienne

This is a very good question from reader SillyWolf. I know several of us have been wondering how to concatenate spectral line data sets that have approx. the same wavelength coverage, but different channel setups (different widths, different centers). So any advice would be greatly appreciated by many people!

There are two VLA archive data which were observed in spectral line mode.
These two archive data cover very similar frequency range.
The point is that:
not only they have different pointing center (about 1 arcmin away from each other), but also their reference frequencies do not match each other, so their frequencies don't match channel by channel !!
I want to combine these two data together. can I use DBCON to combine them in UV domain, or I have to resample one of these datacubes in image domain and combine them together?

Read more!

Averaging Image Channels

Here is a good question from Sanch:

I am trying to average spectral channels in an image cube. Can anyone suggest what's the best way
to do it in AIPS?
I don't want to go back to the UV data and re-reduce it to get the image, as the data I am
working on is huge (VLBI data).

And some more details:

She wants to average together channels in a channel map. In other words, she has a channel map with, say, 100 channels and she wants to turn it into a map with 50 channels. Channels 1 and 2 would be averaged together and become the new "Channel 1," channels 3 and 4 would be averaged together and become the new "Channel 2," and so on.

Thoughts, AIPS gurus?

Read more!

Mosaicing: AIPS/Miriad/whatever works!

Is anyone familiar with mosacing techniques in AIPS, Miriad, or both? I have 21cm VLA spectral line data, taken mosaic-style, and am having a heck of a time trying to stitch the pointings together. Here's what I have done so far:

Reduced in the standard manner with AIPS up until the 'SPLIT' step
Wrote out each pointing with FITTP
Loaded into Miriad
In Miriad, 'invert', 'mossdi', and 'restor', mostly with the defaults for parameters

The best way I can describe the results is like a bad patchwork quilt...does anyone know of a good cookbook or guide for putting together pointings into a mosaic? I know AIPS has some tasks for this (VTESS/UTESS/LTESS) but I haven't had success with them. Thanks!

Katie

Read more!

SMOTH and and regridding

Can anyone suggest an AIPS task that can help me with the following? I'm looking at emission lines in a diffuse source. I needed to try and increase my S/N levels, but could not smooth the line because it has some complicated structure (multiple velocity components, etc) that I want to fit. So, I smoothed spatially using SMOTH.

Since my beam is now almost twice the size that it used to be (6'' instead of 4'') I think the pixel size of the original image may be oversampling the beam. Can I regrid the smoothed image to have 1'' pixels instead of 0.5'' pixels? How?

Thanks,
Katie

Read more!

Reference Frequencies (Center v. Edge?)

I've come to the conclusion that for 1-channel continuum data coming from the VLA, the frequency that you see in the header and in your LISTR 'scans' ouput is the center of your bandwidth (not the beginning).

I come to this conclusion mostly because the L-band observing guide on the VLA web page says that "The two recommended center frequencies are 1365 and 1435 MHz." I used the defaults when I made my observe files, and now my LISTR output lists these two frequencies.

EDIT: June 21 2007
And these words from Eric Greisen

In FITS coordinates, the stated coordinate is at the center of each
voxel.  It may be moved by having a non-integer reference pixel.  In
normal VLA data we do not do that, so these frequencies are nominally
at the center of your band.  I say nominally, because if the bandshape
is not symmetric about the center, then the effective frequency will
diverge from the one stated.  True astrometry should never be done
with wide, asymmetric bandshapes (and the VLA at 50 MHz is
asymmetric).

Read more!

Reference Frequencies (AIPS v. Miriad)

I went back and reviewed my early post; this is an update, with a few more details.

I've been working with GMRT data reduced in AIPS, and ATCA data reduced in MIRIAD.
It turns out that (at least for GMRT observations) AIPS gives the reference frequency (in imhead or prtan) as the frequency in the middle of the first channel, whereas Miriad gives the reference frequency (in prthd or uvlist, options=spectral) as that measured at the end of the first channel. But don't freak out yet--the channels still contain the same data, they are just identified differently in AIPS vs Miriad. See "read more" for details.


It's relatively easy to see from reading the headers, so I'm not sure why this caused me trouble when I first posted it (notice the "at Pixel" in the AIPS header):

From AIPS:

AIPS 1: Image=NGC2997 (UV) Filename=15JAN .UVLIN . 1
AIPS 1: Telescope=GMRT Receiver=GMRT
AIPS 1: Observer=PISANO User #= 43
AIPS 1: Observ. date=14-JAN-2007 Map date=18-APR-2007
AIPS 1: # visibilities 325734 Sort order TB
AIPS 1: Rand axes: UU-L-SIN VV-L-SIN WW-L-SIN BASELINE TIME1
AIPS 1: WEIGHT SCALE
AIPS 1: ----------------------------------------------------------------
AIPS 1: Type Pixels Coord value at Pixel Coord incr Rotat
AIPS 1: COMPLEX 1 1.0000000E+00 1.00 1.0000000E+00 0.00
AIPS 1: STOKES 2 -1.0000000E+00 1.00 -1.0000000E+00 0.00
AIPS 1: FREQ 128 1.4129999E+09 0.50 3.1250000E+04 0.00
AIPS 1: IF 1 1.0000000E+00 1.00 1.0000000E+00 0.00
AIPS 1: RA 1 09 45 38.811 1.00 3600.000 0.00
AIPS 1: DEC 1 -31 09 27.768 1.00 3600.000 0.00
AIPS 1: ----------------------------------------------------------------
AIPS 1: Coordinate equinox 2000.00
AIPS 1: Rest freq 0.000 Vel type: RADIO wrt YOU
AIPS 1: Alt ref. value 0.00000E+00 wrt pixel 1.00
AIPS 1: Max version number of extension files type HI is 1
AIPS 1: Max version number of extension files type FQ is 1
AIPS 1: Max version number of extension files type AN is 1

From MIRIAD:

****************************************************************
Filename: 15jan.uvlin/
Telescope: GMRT
Object: ngc2997 Observer: PISANO
First time: 07JAN15:18:31:06.8
Number of antennae: 30
Polarisations Present: RR,LL
Type of correlations present: crosscorrelation
----------------------------------------------------------------
Spectral Correlations:
Spectrum Channels Freq(chan=1) Increment Restfreq
1 128 1.41302 0.000031 1.42041 GHz
Total number of correlations: 83387904
Correlations are stored in 16-bit form
----------------------------------------------------------------
J2000 Source RA: 9:45:38.811 Dec: -31:09:27.76
Apparent Source RA: 9:45:58.554 Dec: -31:11:18.61

As a side note, when checking the reference freq in AIPS check the outputs of both imhead and prtan--an AIPS bug is that occassionally they don't match!
From Chapter 8 of the AIPS cookbook:
"Another, more serious, problem is that two locations in the FITS file give the "reference frequency" -- the header and the antenna table. In principle these should agree. However there are instances when they will differ. Task FITS will issue a warning when this happens, and will use the antenna table reference frequency as the true reference frequency. In some cases this will be the correct frequency. In others it will not."...pg 8-7

**Note, this is now consistent with one of Laura's later posts (Edited by KMH 9/6/07).

Read more!

XYZ

What does AIPS consider the x, y, and z axes? For example, XSMTH smoothes your data along the x axis. What on earth does this mean? I would think the z axis would be velocity.

Read more!

Continuum Subtraction & POSSM

I'm reducing line (OH 1665/1667 MHz) VLA data for the first time, and I don't know if I should trust my continuum subtraction. When I make an image, it looks like most of my continuum structure is gone, but....when I look at the continuum-subtracted baseline-based spectra in POSSM, the spectra look pretty much exactly the same as they did before I subtracted the continuum.

I would expect that if the spectra had an average value of the continuum of say 2 originally, after the continuum subtraction the specta would have an average value of zero, with emission being positive and absorption negative. But it appears that they still have a value of 2.

What does this mean? Any ideas? Oh yeah, I'm using UVLIN.

Read more!

Help with continuum subtraction?

I have 23GHz spectral line data with a weak continuum source, and need help making the continuum go away so I can measure the strength of the line emission... for a couple subtle reasons, UVLSF won't do the trick in this case. Any ideas for other ways to remove continuum? More details below.



The source itself is a weak point source. The problem with UVLSF is that spectral line structure is found across much of the spectral window, making it really hard to find line-free channels to average together to use as a model for the continuum. UVSUB uses clean component models, and honestly, I'm not sure how to use it or indeed if this is really what I want.

An additional twist-- I have a higher S/N image of the continuum source taken in an image of the same field at a slightly different central freq (~1.5 GHz offset). I have a feeling I can use this continuum emission as a better S/N image to subtract from the original image, but I'm not sure how to do this...

Ideas? Thanks...

Read more!

Smoothing in BPASS

What is up with all those warnings about smoothing in BPASS? It seems so fricking absurd that you can only smooth your bandpasses if you smooth your data.

(One of my data sets had very high spectral resolution, so each channel was quite narrow and typical integration times on bandpass calibrators led to very noisy bandpasses. Of course, I didn't want to add all this noise to my data, but I did want to calibrate the bandpasses. A good solution to this would be to simply smooth the bandpasses, so that you'd get the general shape of the bandpass without all the nasty channel-to-channel variations.) But is smoothing ok? I don't want to sacrifice the resolution of my data!

This advice in from Katie Devine at the VLA in NM:

Hey, I learned something today that you'll find interesting: the smooth warnings for smoothing the data itself can be ignored if you have an antenna with intrinsically nice bandpasses. The reasoning is such-- if you have a really crazy bandpass (like on the GMRT for example) that has large dips, and you smooth those out with out smoothing the data, then a line that may have fallen in a dip in the bandpass will not be calibrated properly, because that dip will have been smoothed out (make sense? I can clarify if you want).

On the other hand, the bandpass for the VLA just has a little bit of noise to it, but no other intrinsic shapes. So smoothing the bandpass without smoothing the data is ok in this case. Basically, your gut instinct was correct.

You'll want that bpass correction if you're citing line strengths, especially if you have more than one line in each band...

Read more!