Casapy and miriad creating different results!?

Do you use (or want to use) other tools to reduce ATCA data?

Moderator: Mark.Wieringa

Casapy and miriad creating different results!?

Postby Arpad » Thu Sep 06, 2012 9:03 pm


I've got a problem, once again.

I noticed that there is something wrong when I checked results of the cleaning of ATCA Cabb data. I tried it in miriad and casa. The first part, the initial calibration, of it was the same for both. I exported the miriad files to uvfits, imported it to casa, did the calibration. Then I imaged the data in casa. For miriad, I exported it again to uvfits and imported it to miriad. There I also imaged it. And now the big surprise, at least for me, is that stokes Q and U have completely different values. Which is bad if one plans to do rotation measure synthesis on this data.

To verify this I created a simulated observation with uvgen. I used a 10 Jy point source with 10% linear polarization. After using invert and just taking the central pixel of the dirty map, I got the following values for i,q,u,v:
10 Jy, 1027.46 mJy, -2.9 mJy, 15.77 mJy.
and for casa (using 0 iterations to get the dirty image):

10 Jy, -13.35 mJy, 547.04 mJy, 16.43 mJy.

Curiously, stokes V is very similar in both, but Q and U are completely different. Also, the PI in the miriad image is 10%, and in miriad only about 5%.
Now I would say that at the moment I cannot say which of these results is more reliable. I guess that invert would probably create the "true" result since the data was created in miriad. But it would be good if someone could clear that up. Is there some flaw in casa and linear feeds? or am I missing something?

edit: I just checked if the uvfits import/export might be the reason. I exported the testdata to uvfits, and then imported it right back to invert it again. Stokes I, Q and V are the same (in Q there is a very slight difference), but U changes from -2.9 mJy to 8 mJy for the central pixel. Maybe the uvfits format is not properly exported?

Posts: 12
Joined: Thu Feb 24, 2011 1:50 am
Location: Germany

Re: Casapy and miriad creating different results!?

Postby Mark.Wieringa » Fri Sep 07, 2012 3:11 pm

Hi Arpad,

thanks for your query, verifying CASApy works for CABB data is something we have not looked at in enough detail so far, especially not for polarization data.

To be able to recreate your test we'll need some more information:
- the inputs for uvgen and fits (both ways)
- any calibration steps performed
- what you did in casa to get from uvfits to image

The difference in Q and U going from miriad to CASApy could be due to confusion about the linear polarization labels in miriad, if CASApy is interpreting the data as circular polarization or the feed angle/parallactic angle rotation is wrong you could get effects like you observed.

On the uvfits import/export test: since you are getting about 15 mJy in Stokes V (which should be 0) I'm assuming that is the level to which we can trust the imaging process - there may be slight variations in weighting etc. after fits conversion. You could make a difference image of the beam to check this.


ATCA Expert
Posts: 284
Joined: Mon Feb 08, 2010 1:37 pm

Re: Casapy and miriad creating different results!?

Postby Arpad » Fri Sep 07, 2012 8:38 pm

Hi Mark,

Here are the uvgen parameters:
source = $MIRCAT/qpoint_test.source
ant = $MIRCAT/h168.ant
baseunit = -51.0204
telescop = ATCA
corr = 0,1,0,104
spectra =
time =
freq = 1.38
radec = 0,-50
harange = -6,6,0.01
ellim = 12
stokes = xx,yy,xy,yx
polar =
leakage = 2
zeeman =
lat = -30
cycle = 0.1,0.4
pbfwhm =
center =
gnoise =
pnoise =
systemp = 50
tpower =
jyperk = 12.7
options =
out = testfile.miriad

I got most of the settings from using source and then a file called uvgen.def.atca or something like that. I think its in the handbook. qpoint_test.source is based on the packaged file qpoint.source, where I just changed the flux and the linear polarization. The file looks like this:
10.0000 0.0000 0.0000 0.0000 0.0000 0.0000 10.0000 0.0000

without any calibration steps, doing a quick invert to get the dirty image:
beam= i.beam
imsize= 500
cell = 3
robust = 0
stokes = i,q,u,v

This should create the dirty images with the values that I described in the previous post. The values were always taken from the central pixel, using this geometry it would be pixel 250,250.

As for the fits export/import test:
to export:
in = testfile.miriad
op = uvout
out = testfile.uvfits

and back in:
in = testfile.uvfits
op = uvin
out = testfile_new.miriad

I tried several of the options available for uvin and uvout, but none of them recreated the same image.

and for Casa (3.4):


The rest of the clean parameters had default values. Exportfits was used to be able to look at the image in kvis, since kvis cannot read casa images.

I dont think that that casapy interprets the data as circular, because listobs, the task that prints out information about the dataset, correctly shows XX,YY... as polarization products. Although I could imagine that a misinterpretation could still happen within the clean task.

btw: I dont think that this is specific to cabb data, because a collegue and I tested the values resulting from miriad and casapy using precabb data. There the stokes q und u values were also not the same.
Posts: 12
Joined: Thu Feb 24, 2011 1:50 am
Location: Germany

Re: Casapy and miriad creating different results!?

Postby Mark.Wieringa » Tue Sep 11, 2012 4:38 pm

Hi Arpad,

I just reran the miriad part of your simulation and found that if I specify stokes=i,q,u,v in the fits export, and then read it back in, I get exactly the same values for i,q,u and v in the image as before. Looking into this some more, it turns out that the difference in U appears because of a slight difference in the variable chi, the parallactic angle. It gets recomputed by fits when it loads the data, based on the epoch of the observation. uvgen labels everything as J2000, even though it is actually generating data for the epoch of the observation (as specified with the time keyword). If you set time=00JAN01 in uvgen, the differences disappear.

I'll try to reproduce the casa issue tomorrow. I'm suspecting a similar issue, but I haven't got the code for it so I think all we'll be able to do is submit a bug report for casa.


ATCA Expert
Posts: 284
Joined: Mon Feb 08, 2010 1:37 pm

Return to Other Tools

Who is online

Users browsing this forum: No registered users and 1 guest