Hi Eric, <br><br> Sorry, I forgot to respond to your question. Yes I used <br>uvw provided in the WSRT data to image. According to the <br>header the three baseline axes are marked as: <br><br>AIPS 1: Rand axes: UU-L VV-L WW-L BASELINE TIME1<br>
<br>Since there is no suffix I guess AIPS assumes that it is SIN projection. <br>This is not correct and should be NCP.<br><br>cheers,<br>Neeraj<br><br><br><br><br><br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 9:21 PM, Eric Greisen <span dir="ltr"><<a href="mailto:egreisen@nrao.edu">egreisen@nrao.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">Neeraj Gupta wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Dear Eric,<br>
<br>
I write this mail to request some help to understand an issue<br>
that I have come across while analysing WSRT dataset with AIPS<br>
31DEC10. <br>
This is one full-synthesis L-band dataset with 20-MHz BW<br>
split into 1024 channels. Analysing it with AIPS I find that<br>
position of all the sources away from the phase-centre are<br>
systematically offset by 5-10" wrt the FIRST catalogue. The<br>
position of radio source at the phase centre however seems to<br>
match well. All the offsets are in about the same direction as seen in one of the plots attached (see contour plot - AIPSIMAG.png<br>
- for one of the sources where crosses are positions from FIRST). Therefore it is difficult to explain these offsets by some error in<br>
time or frequency. The WSRT beam is about 40" in the N-S<br>
direction but the offsets are significant as they are seen more or<br>
less for all the sources that are away from phase-centre. <br>
To check this further I imaged the same dataset with CASAPY<br>
and found that the same offsets are reproduced when I make the<br>
contour plots in AIPS with KNTR (see CASAIMAG.png). The<br>
image produced with MIRIAD however shows no offsets<br>
(see MIRIADIMAG.png). <br>
However when I see these same images through casaviewer,<br>
I find that the MIRIAD and CASAPY images are well aligned<br>
wrt each other whereas only AIPS image is offset. See the<br>
images MIRIADinCASA.png, CASAinCASA.png and AIPSinCASA.png. In all the three cases, contour plot correspond to MIRIAD image that<br>
matches well with the FIRST catalogue positions. <br>
In short, image produced with MIRIAD (which as NCP projection)<br>
appears correct in both the AIPS and CASAPY. On the other hand<br>
image produced with AIPS appear to be offset both in the AIPS<br>
as well as casaviewer. <br>
I also imaged using AIPS the dataset that was calibrated in MIRIAD<br>
to create the MIRIAD image and AIPS still produces the offsets.<br>
<br>
Therefore, at this point it is not clear to me if this the problem is related<br>
to viewer or the dataset or even specific to WSRT itself. <br>
I am also attaching two FITS files with this mail:<br>
<br>
NGC3226SC.FITS: This is dataset that was calibrated in MIRIAD. Imaging this in MIRIAD produces an image (also attached as<br>
NGC3226MIIRIAD.FITS) that shows no offsets wrt FIRST. The same<br>
dataset when imaged in AIPS shows offsets for off-centre sources. <br>
<br>
I will greatly appreciate any information or help that you can provide<br>
on this issue.<br>
</blockquote>
<br></div></div>
I suspect the issue to be the following:<br>
<br>
Have you simply used the u-v-w provided in the WSRT data? If so, they are computed on a special NCP projection rather than -SIN. Were you to change the image header of an IMAGR output to say RA---NCP and DEC--NCP rather than RA---SIN, DEC--SIN which it now says, I suspect that the source coordinates will line up. Alternatively, run UVFIX on the data before imaging in AIPS and then make images. They will not line up with the others, but the source coordinates will. I suspect it is all a matter of imaging geometry.<br>
<font color="#888888">
<br>
Eric Greisen<br>
</font></blockquote></div><br>