Watch out for those FreqIDs!

If you're a continuum observer (especially if you use the single-channel, 50 MHz correlator setting at the VLA), it's important to remember when reducing line data that each different set of frequencies in line data is given its own FreqID number. Some tasks work fine with datasets with multiple FreqIDs (e.g., LISTR), but other tasks (e.g., TVFLG or SPFLG) need to be told what FREQID to use or they won't find the data. You can control how the FREQIDs are assigned in FILLM.

Read more!

Bad Gain Exponents

I'm trying to calibrate some archival VLA HI data from 1989 and FILLM keeps giving me scary messages about BAD GAIN EXPONENTS, e.g.,

MCCHED: 0/02:34:45.0 12 x 12 BAD GAIN EXPONENT 26

AIPS seems to really not like this. The source table of the resulting data file only contains the first source observed, which is not right. I'm was going to be more aggressive about the FILLM selection parameters to avoid the bad times, but was wondering if anyone else has encountered this?

EDIT: After playing with the TIMERANG keyword for FILLM, it seems like this is a problem with how AIPS is reading in the file. Everytime I change the TIMERANG keyword, the data with the BAD GAIN EXPONENTS changes to the earliest data in the file. Weird.

Read more!

Importing Miriad files into AIPS

A question from Danny:

Hello AIPS ninjas.

Is there any way to import miriad *.uv files -the kind that are whole directories full of binary files- into AIPS?

~Danny

Read more!

Missing Scans!

I'm reducing some EVLA-VLA data, and I discovered that one of the calibrator scans was missing in the data. It was listed in the "scan list" on the archive and the observe files were (to the best of our knowledge) correct. After emailing the analysts, we figured out that the scan was flagged by the online flagger. You can read in the data without applying these online flags using CPARM(3) = 16.

I'm still trying to figure out why it was flagged, and I'm assuming that this information is stored in the "OF Table" extension. However, I haven't been able to find any information on that table using google (googling "aips 'OF table'" doesn't really work because you get a lot of pages with properties of tables, not info about the OF table).

I'll post what I learn about this (if anything), but it's something to keep in mind if you find yourself missing scans..

Read more!

Importing AIPS images into IRAF

Here is a question from reader donkeypuncher:

I'd like to use IRAF to do some analysis on images produced in AIPS. Alas, I am unable to open in IRAF the FITS files output by AIPS (task FITTP). I get this simple, non-informative message when I attempt to use the IRAF task display:

ERROR: Cannot open image (IMAGE.FITS)

I'm guessing it's a format issue, because I have no problem loading in ds9. Any ideas?

BTW, I like the site, thanks for your contributions!

My guess at an answer can be found if you click below..

I think that IRAF needs and expects the '.fits' suffix to be in all small letters. Try changing your image name to 'image.fits' and see if that helps.
Also-- something else I've noticed is that optical software often freaks out at the small pixel values in AIPS images (For example, are your pixel values on the order 10^-3 to 10^-6?). Once you get your image into IRAF, you might want to try multiplying your entire image by some large constant, say a million, using imarith. This could potentially save you headaches.

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!

WBR Step 1. Loading in Your Data

Ok, I'm going to start writing an introduction and overview of how to reduce data in AIPS for our REU students this summer. I think the AIPS cookbook overview is vague and opaque, so maybe this will help fill in some gaps. Starting with...FILLM!



From the archive, you'll probably have several files with the observing code, an underscore, and a number. For example: AS755_1.
Move all of the files for your relevant observing program into a convenient directory. Start aips from there.

Now it is time to load these data into AIPS, using the task FILLM. The most important parameters to input here are:
INFILE: pwd will tell it to look for the files in the directory you just started aips from. give it the observing code and an underscore as a prefix.
VLAOBS: give it your observing code
OUTNAME: you can give your data some cute name when it is loaded into aips
DOWEIGHT = 1: you want to load in the data weights!! important!
most of the other parameters here i still don't really understand. I bet some of the time-averaging parameters under CPARM are quite useful, but I'm not sure which are most important to think about. The defaults are probably fine if you're just beginning.

AIPS 1: FILLM     Task to read a VLA archive tape
AIPS 1: Adverbs     Values                 Comments
AIPS 1: ----------------------------------------------------------------
AIPS 1: INTAPE        1                    Tape drive number
AIPS 1: INFILE     'PWD:AS755_'            Non-blank: disk file name
AIPS 1: NFILES        0                    Number of files to advance
AIPS 1:                                    Also applies to ON-LINE!
AIPS 1: BAND       ' '                     Freq. band (4,P,L,C,X,U,K,Q)
AIPS 1: QUAL         -1                    Source qualifier -1=>all
AIPS 1: CALCODE    ' '                     Calibrator code
AIPS 1: VLAOBS     'AS755'                 VLA obs. pgm. name ('AZ99')
AIPS 1: VLAMODE    ' '                     VLA obs. mode ('  '=any)
AIPS 1: REFDATE    ' '                     Reference date. 'yyyymmdd'
AIPS 1: TIMERANG   *all 0                  Timerange selected
AIPS 1: BCHAN         1                    First spectral channel
AIPS 1: ECHAN         0                    Highest spectral channel
AIPS 1: OUTNAME    ' '                     Output UV file name (name)
AIPS 1: OUTSEQ        0                    Output UV file name (seq. #)
AIPS 1: OUTDISK       1                    Output UV file disk unit #.
AIPS 1: DOUVCOMP      1                    1 (T) => compressed data
AIPS 1: DOALL        -1                    1 (T) => write all data.
AIPS 1: DOCONCAT     -1                    1 (T) => append data to old
AIPS 1:                                    files
AIPS 1: NCOUNT        0                    Number of files to read
AIPS 1: DOWEIGHT      1                    Use nominal sensitivity to
AIPS 1:                                    scale weights?
AIPS 1:                                    = 10, use Memo 108 weights
AIPS 1: DOACOR       -1                    Load autocorrelation data?
AIPS 1: CPARM         0           0        User options.
AIPS 1:               0           0        1 => Avg. time (seconds)
AIPS 1:               0           0        2 => bitmap    (see help)
AIPS 1:               0           1             = 16 for planets & Sun
AIPS 1:               1           0        3 => Max. OK IF status
AIPS 1:                                         <=3 => 3
AIPS 1:                                    4 => Control dropping of
AIPS 1:                                         shadowed data
AIPS 1:                                         < 0 => no shadow check
AIPS 1:                                         0 => 25 m limit
AIPS 1:                                         > 0 => Shadow limit is
AIPS 1:                                               CPARM(4) in meters
AIPS 1:                                    5 = channel code (see HELP)
AIPS 1:                                    6 => Subarray number-see HELP
AIPS 1:                                    7 => FQ entry tolerance (kHz)
AIPS 1:                                         (see HELP)
AIPS 1:                                    8 => CL table time incr. min
AIPS 1:                                    9 => TY table time incr. min
AIPS 1:                                    10=> Calibrator avg. time
AIPS 1: DPARM      *all 0                  Selection by Frequency
AIPS 1:                                    1+2 => A Frequency (Hz)
AIPS 1:                                    3+4 => B Frequency (Hz)
AIPS 1:                                    5+6 => C Frequency (Hz)
AIPS 1:                                    7+8 => D Frequency (Hz)
AIPS 1:                                    9 => tolerance for A&C
AIPS 1:                                    10 => tolerance for B&D
AIPS 1: BPARM      *all 0                  Opacity and Gain curve   
AIPS 1:                                    control (see help)
AIPS 1: IN2FILE    *all ' '                Antenna gains file

Watch the output and make sure AIPS read in the data from all of your files. After FILLM successfully runs, if you type "uc", you should see two files: one CH 0 and one LINE. The CH 0 data is basically the line data with the channels averaged together (well, the central 75% of channels). CH 0 data may be useful for calibration.

Read more!

Number of Channels = One Less Than I Expect

4/2/07: When I write my observe file, I ask for 8 channels. And when I get the data and FILLM, there are always 7 channels there.
Now, I have a new data set in which I asked for 4 channesl, and when I FILLM I am again missing a channel, there are only 3! This is a pretty significant loss of signal; I'd like that channel back.

I think I'm using pretty standard, default parameters in FILLM. Has anyone ever found a way around this problem? (I'm sure it's not a big deal if you're doing bona fide spectral line data).

UPDATE as of 4/14/07: After talking to my advisor Eric, it appears that Channel 0 actually counts as one of your channels!!! So when you ask for a correlator setup of 4 channels, you actually get 3 channels of original data, and then one of the channels is taken up by the average of these, CH 0. This is really one of the stupider things I've heard yet about radio interferometry. And let this be a warning to you, don't ever ever use the 2-channel correlator setup at the VLA!!!! I guess it's the same as doing continuum observations, but with less bandwidth!

Read more!