CVEL and DBCON with ATCA Data

I'm reducing some archival, multi-configuration HI data from the ATCA and am having trouble getting the velocity axis quite right. I've put the correct velocity definition in the header using CVEL and then am combining the individual data sets using DBCON with DOPOS=1,1 so it checks the position and frequency information in the header. However, when I make the image and compare to the originally published image the velocities for various features are way off (~40 to 100 km/s). Any words of wisdom from the peanut gallery on using CVEL and DBCON together?

I've mostly been following The Analysis of ATCA data with AIPS, but it's a little light on detail on this issue.

Read more!

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!

Clean Boxes from SETFC

Here is a question from an anonymous reader:

I'm new to AIPS, and noticed that using SETFC automatically sets clean boxes for every facet, the same size as every facet. When I've been wide field imaging, I've just been adding smaller clean boxes around sources on top of these. Is this ok, or is it better to delete these automatic boxes, and just manually add ones around obvious sources? Thanks.

I think I know the answer to this, if you click to read on...

You definitely want to delete the big clean box. By and large, you don't want clean boxes to overlap, and you do not want to clean your entire field (which is what you're doing if you leave that big clean box). Someone at NRAO once really stressed to me that you want your clean boxes placed as tightly around the real flux in your sources as possible. So get rid of those big boxes.

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!

Kvis & AIPS awesomeness!

You can use kvis to view your AIPS images directly! See below for more details. Thanks to Bryan Gaensler for this awesome tip.



The program kvis is an image viewer that is part of the karma image analysis package. An undocumented, but cool feature of this program is that if you navigate to your AIPS data directory (typically somewhere like $AIPS_ROOT/DATA/LOCALHOST_1) in the kvis file selector you will see each AIPS image file with its correct name (instead of crytic filenames like FQD001001.099;) and be able to click on them and view them. Once you've got then in kvis, you can even save to FITS.

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!