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!

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!

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!

How does DBCON deal with flagging?

Does anybody out there understand how DBCON flags your data? The help file is being less than transparent. DBCON seems to copy over all the FG tables from the first image you give it to the DBCON'd file, but does not appear to copy FG tables from the second image.

There is this note in the help file:
"Also, any CL, FG, TY, WX, IM, MC, PC, AT, CT, OB, or GC tables with version=1 will have their source numbers translated and appended to the end of the corresponding table (if any) from the first file."
So, let's say I have 13 flag tables for Image1 and 6 flag tables for Image2 (which happens a lot with the new crazy FG table creation scheme). Does this mean FG #1 for Image2 gets appended to FG tables 1-13 from Image1? And then in the futere, I will be apply a combination of FG#1 to Image1 and FG #13 to Image2? That's kinda dumb...

Read more!

Self Calibration and DBCON

Let's say you have two data sets that you want to DBCON together. Should you self calibrate them individually? or after DBCONing?

The tip I got is you should self-cal each data set individually as best you can, then DBCON. However, after DBCONing, there might be some small gain offsets between the two data sets. Do a final A&P self cal on the DBCONed data set with a really long SOLINT, so that you basically have one SN solution per data set. This will ensure the original data sets are as consistent with one another as possible.

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!

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!