Imaging equatorial sources

[Jess Broderick]

Hi,

I'm trying to make an image of a source at Dec -00:20:45. The data were obtained with the H168 configuration on March 23/24 at 5.5 and 9 GHz (project CX188). I have no problems with the calibration, but the dirty map produced with INVERT doesn't look quite right. First of all, the cell size changes across the image (at least according to KVIS); this happens if I let INVERT choose the default pixel size or I specify it myself. Secondly, there are some sources in the field whose positions I know from NVSS; they appear to have been shifted in my higher-frequency images.

Any suggestions? Even with the spur, is it possible to get a good image so close to the celestial equator?

Thanks,
Jess

[Mark.Wieringa]

Hi Jess,

I had a look at an image I made with dec=1d20m and it shows similarly bad behaviour. In kvis the pixel size is constant, but when I get close to dec 0 (0d03m) the coordinate conversion blows up and shows -2 billion degrees for dec (-MAXINT). Kvis also refuses to label the declination axes or draw a coordinate grid. I tried cgdisp, but it fails with a coordinate conversion error after plotting a tall narrow image. I suspect the problem is invert uses the NCP map projection which is not defined when you cross the equator, I believe it should be able to use the more general SIN projection, but I can't find a switch for it.

I'll forward this to Mark Calabretta as he is our coordinate system expert. It might help if you can deposit a small uv file and image that show the problem on an atnf machine somewhere.

Cheers,

Mark

[len067]

Hi All,

Mark's correct, it has to do with the NCP map projection. I recall that Attila Popping and Robert Braun ran into a similar problem with an ATCA survey they were doing around an equatorial region. It may be worthwhile getting in contact with them to see if they found a way to circumvent this issue. I'm actually on sick leave at the moment but next time I get into the office I'll ask Robert about this (unless he happens to be reading the forums?).

Cheers,

Emil.

[Jess Broderick]

Hi Mark and Emil,

Thanks for your replies/suggestions. I've put the following files in /DATA/KAPUTAR_3/bro829/ : a0620-00.5756 and a0620.map

Cheers,
Jess

[len067]

Hi Jess,

FYI, I asked Robert (via email) about this problem. Unfortunately it seems that they didn't arrive at any solution except to truncate their mosaic coverage to avoid the problematic regions

Cheers,

Emil.

[Mark.Wieringa]

Hi Jess,

I had a play with the files you provided and found that if you make an image without antenna 6 (select=-ant(6) in invert) it will have the SIN projection. This image behaves nicely in kvis and cgdisp. There is a check in the coordinate routines that switches between NCP and SIN projection depending on how 'East-West' the array is. In this case there is a 20 to 1 ratio between longest E-W and longest N-S baselines which causes invert to assume the E-W optimized NCP projection is best.

Hope this helps somewhat,

Mark

[Jess Broderick]

Hi Mark,

Thanks for having a look at my files. Are the coordinate routines in invert.for? If possible I would like to see if I can modify the code so that it uses SIN projection with the antenna 6 data included; the long baselines are important for our project.

Jess

[Mark.Wieringa]

Hi Jess,

ok, if you're a black belt user - look in miriad/subs/hdtab.for for the following code in routine HdSet

if(sumlumv/sumuuvv.lt.tol)then
proj = 'NCP'
else
proj = 'SIN'
endif

You'd want to set tol to something much smaller than 0.01, recompile hdtab and then rebuild invert.

Cheers,

Mark

[Mark.Wieringa]

Mark Calabretta has now implemented a "sin" option in invert and made the defaults more sensible.

sin Label the output map and beam as a SIN projection.
Default is NCP unless non-east-west baselines are
present or the field centre is within 3 deg of the
celestial equator (because NCP blows up near the
equator). Note that this option simply changes
ctype1 and ctype2 in the header, the translation
only being correct to first order about the field
centre. A similar result could be obtained by
running 'puthd' on the output map, e.g.
puthd in=<map>/ctype1 value=RA---SIN
puthd in=<map>/ctype2 value=DEC--SIN
and likewise for the beam.

This is in Revision: 1.10, 2010/05/18 05:06:42 UTC.