[daip] AIPS question....

[Eric Greisen]

caromora at mpifr-bonn.mpg.de wrote:
> Dear Dr. Eric Greisen,
> 
> 
>                      Please receive my regards! I am a PhD student in 
> MPIfR Bonn, Germany. I was in the ''VLA Data Reduction Workshop'' in 
> NRAO 2 weeks ago. I tried to talk to an AIPS specialist while I was 
> there but unfortunately I could not find you. I hope you can help me 
> with a problem I have just discovered in my data. I have merged VLA and 
> Effelsberg data at 2 wavelengths (3.6 and 6.2cm) of the edge-on spiral 
> galaxy NGC 4631. The main purpose of my project is to study the magnetic 
> field orientation in the disk of the galaxy, hence I need detailed 
> definition in Stokes Q and U. Before merging the VLA and Effelsberg data 
> at each wavelength I needed to align the maps, which I did with the task 
> ''OHGEO''.
> 
>                      Now I am trying to create a spectral index map of 
> the galaxy with the Effelsberg maps alone. To do this I also needed to 
> align the two Effelsberg maps. When I align the 6.2cm-Effelsberg map to 
> the geometry of the 3.6cm-Efflesberg map with the task ''OHGEO'' I 
> obtain a map with irregular and rough contours. In addition, the 
> spectral index map I obtain with this ''re-aligned'' map has a 
> pixel-like non-smooth distribution. However, when I align the maps with 
> the task ''HGEOM'' I obtain smoother and better results. I infer that 
> the task ''HGEOM'' seems to be doing a better interpolation than 
> ''OHGEO''. Now that I have tested these tasks and seen the evident 
> difference, my concern is if this ''poor'' interpolation of ''OHGEO'' 
> can also affect my merged maps. I have merged using the task ''IMERG'', 
> which is suppose to merge in the UV-plane and not in the image plane. Do 
> you think that aligning the maps with ''HGEOM'' before merging them can 
> reflect a significant difference in my merged map?

OHGEO has the adverb REWEIGHT which controls the accuracy of the 
interpolation and for a change from large pixels to quite small you 
should probably not use the default (0 -> 1 but instead 3 or 4).
HGEOM has a similar parameter (APARM(1)) but the default is "bi-cubic" 
which should be more accurate than the default in OHGEO.

Both tasks, when used to adequate accuracy, give similar results.  HGEOM 
will expand areas of blanked pixels, whilst OHGEO tends to contract 
them.  HGEOM at the highest interpolants can sometimes produce negatives 
from a map that is all positive!  It actually fits the data and such 
fits can have negatives while running through the all positive data 
points.  In general, I prefer OHGEO but with REWEIGHT(1) set to 3 or 4.

Eric Greisen