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!

Combining Data with Different Pointings

Here is a question from reader Korinne:

I have data from three VLA pointings in L band at the same frequency (with the same channel width) but with different pointing centres which cover an area of an object and partially overlap, unintentionally as the pointings don't overlap at the other frequency we observed that the observations were mostly set up for.

What is the best way to combine this data? I initially imaged and cleaned and then combined with flatn, but it seems like there might be some way to do it at the uv level, but from my readings of the cookbook I can't figure out how I would go about that, particularly in slightly more detail.

My answer below the fold...

I think you want DBCON, which can concatenate data in UV space. Try reading this post. The answer is basically that it depends on just how different your different data pointing are.

If you are actually talking about mosaicing a source, where your various pointings are offset by significant fractions of the primary beam, then FLATN might be your best bet. A bit more discussion of mosaicing here.

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!

More Missing Flux Cals

I'm reducing archival data, and a flux calibrator was unfortunately not taken at the beginning and the end of the observation. It was only taken at the beginning, and when I read the data in with FILLM, FILLM says that the antennas moved between my flux cal and my phase cal/data. FILLM then puts the flux cal in a different UV file from the data/phase cal.

I'm thinking the antennas couldn't have moved THAT much over 15 minutes (and all i want is a flux anyway), so I'd still like to use the flux cal (also there are no appropriate recent fluxes for the phase cal in any of the NRAO databases that Claudia suggested.) Is there a way to
a) apply a flux calibration solution from another uv file?
or
b) relax FILLM's requirements so that it will not be so sensitive to moving antennas and put everything in one file?
or
c) append a source to another UV file? I know uvglu appends in frequency, but i don't think it appends sources.

Thanks!

Read more!

Calibrating Data without a Flux Calibrator

Sometimes when I get data from the archive, it appears that the observers have not observed a flux calibrator. There is a phase calibrator. Is it possible to use this data? Is the data really only good for imaging and getting the morphology of an object, but you can not trust it for absolute fluxes? I feel like I should be able to do something clever to get fluxes...

Read more!

DBCONing Data Sets From Different Epochs

If you are an archive monger like me, you might find yourself reducing one J2000. data set and one B1950. data set, and then wanting to concatenate them together. If you try to do this, DBCON will yell at you. So...

You will have to run EPOSWTCH on the 1950 data set to bring it into epoch 2000. However, if you try to run DBCON now, DBCON will still yell at you and say:

tsingt> DBCON1: DEC      AXIS HAS UNEQUAL ATTRIBUTES
tsingt> DBCON1: Purports to die of UNNATURAL causes

As explained by Eric Greisen here , this is because the image you EPOSWTCHed now has a Declination axis with a rotation imposed upon it. For example:

AIPS 1: Image=NGC1569   (UV)         Filename=N1569_3B    .SC_P1 .   1
AIPS 1: Telescope=VLA                Receiver=VLA
AIPS 1: Observer=AA116               User #=   53
AIPS 1: Observ. date=21-AUG-1990     Map date=06-JUN-2008
AIPS 1: # visibilities    135940     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       4  -1.0000000E+00       1.00 -1.0000000E+00    0.00
AIPS 1: FREQ         1   8.4149000E+09       1.00  5.0000000E+07    0.00
AIPS 1: IF           2   1.0000000E+00       1.00  1.0000000E+00    0.00
AIPS 1: RA           1    04 30 49.498       1.00       3600.000    0.00
AIPS 1: DEC          1    64 50 59.587       1.00       3600.000   -0.60
AIPS 1: ----------------------------------------------------------------
AIPS 1: Coordinate equinox 2000.00
AIPS 1: Rest freq      0.000         Vel type: OPTICAL wrt YOU
AIPS 1: Alt ref. value  0.00000E+00  wrt pixel    1.00
AIPS 1: Maximum version number of extension files of type FQ is   1
AIPS 1: Maximum version number of extension files of type HI is   1
AIPS 1: Maximum version number of extension files of type AN is   1
AIPS 1: Maximum version number of extension files of type WX is   1
AIPS 1: Maximum version number of extension files of type FG is   1

You can get rid of this rotation using UVSRT:

AIPS 1: UVSRT:  Task which sorts UV data
AIPS 1: Adverbs     Values                 Comments
AIPS 1: ----------------------------------------------------------------
AIPS 1: INNAME     'N1569_3B'              Input UV file name (name)
AIPS 1: INCLASS    'SC_P1'                 Input UV file name (class)
AIPS 1: INSEQ         1                    Input UV file name (seq. #)
AIPS 1: INDISK        1                    Disk unit # of input UV data
AIPS 1: OUTNAME    ' '                     Sorted UV file name (name)
AIPS 1: OUTCLASS   'ROTAT'                 Sorted UV file name (class)
AIPS 1: OUTSEQ        0                    Sorted UV file name (seq. #)
AIPS 1: OUTDISK       0                    Disk unit # of sorted UV data
AIPS 1:                                      0 => highest with space
AIPS 1:                                    If outfile spec. equals the
AIPS 1:                                    infile spec., output will
AIPS 1:                                    overwrite the input
AIPS 1: BADDISK    *all 0                  Disk drive #'s to avoid
AIPS 1: SORT       ' '                     Two char. sort order, eg.'XY'
AIPS 1:                                    blank => 'XY'
AIPS 1: ROTATE        0.6                  Angle thru which to rotate.
AIPS 1:                                    positive rotates CCW
AIPS 1: DEFER         0                    Defer output file creation?

Note that the ROTATE parameter is the negative of the rotation noted in the header. Now you should be able to DBCON the EPOSWTCHed data with the other J2000 data set!

(You may have to UVSRT the DBCONed data so that it is in TB order again.)

Read more!

Double Sources-- and not the AGN kind

I'm having this problem with some archival data from 1990. I have two nights of data on a galaxy, spaced a few nights apart from one another. I calibrate the nights separately, and image them separately. It rapidly becomes obvious that the images from the two nights are shifted relative to one another, but not in any simple way. The galaxy center, at the image center, is at the same position in both, but as you go out radially, the first night's sources are further out, radially. It's as if the image is stretched one night, relative to the other.

AIPS thinks that both images have the same pixel scale, so that means a source will have different R.A. and Dec (by about an arcminute, pretty bad!) between the two nights' images. If I DBCON the two nights, I get lots of double sources.

The observational setup claims to be exactly the same between the two nights-- same pointing center, same correlator set-up.

Anyone have any idea what might be causing this? I think I've had a similar problem with GMRT data before, and gave up temporarily and went on to a different project. I'm guessing it's a calibration issue?

Read more!

Filling data that includes midnight

When you get your data from the archive, it's normally in several files. For me, each file is usually a day's worth of data, so I fill and calibrate each data file separately. However, if you have observations that go from say 20:00 on 17-Feb to 6:00 on 18-Feb, the archive creates a separate files for the observations on the 17th and for the observations on the 18th. You need to read in both files to calibrate that series of observations.

Read more!

Complications with Shamelessly Raiding the Archive

Amanda and I are spending the week in Socorro, so hopefully we will be learning little new AIPS facts every day! Here's my first one:

Sometimes I have dreams about raiding the VLA archive and combining like 6 different data sets. However, often times the data sets will have slightly different centers-- in my case, often one observer centers on the galaxy's center, while another observer center on a supernova that goes off in the outskirts of the galaxy, some 5 arcminutes away. I was wondering, can you just DBCON these two data sets together, and AIPS can handle it?

The answer is...

DBCON can adjust the phases, so yes, it can image data from two pointings with significantly different centers. What Miller Goss said you have to be wary of is that DBCON doesn't adjust amplitudes. So, if there are two different pointing centers, the center of your galaxy is going to fall in different locations of the primary beam in the different observations. If you are combining two observations separated by 5 arcminutes at 20cm, where the primary beam is 30 arcminutes, this shouldn't be a big issue...probably the primary beam sensitivity of the two pointings will only vary by a few percent. However, if the separation of your pointings starts approaching the size of the primary beam, then you can no longer use DBCON and need to think of some other way to combine the data.

Read more!