[daip] Frequency coordinates(31DEC05 vs 31DEC04)

[Neeraj Gupta]

Dear Eric,

     I am right now at the observatory site and will be awake most of the 
night.  I could spent sometime rechecking the things.  I got the following 
results for the dataset with negative frequency increment:

1)  ISPEC and IMAGR output for 31DEC05 are in disagreement and incorrect 
for the latter.

2)  ISPEC and IMAGR output for 31DEC04 are identical, correct and same as 
that of ISPEC output of 31DEC05.

3)  Checking the FQ table for the IMAGR work file for both the 31DEC04 and 
31DEC05 holds the key. Please see the sign of CH Width in appended 
illustration.

4)  1,2,3 hold for both the single and multi-source file.


     What remedy do you suggest for this??

cheers,
neeraj


#####Following output corresponds to 31DEC05 and is same for both single 
and multi-source files.
AIPS 1: Telescope=GMRT               Receiver=GMRT
AIPS 1: Observer=TCLARKE             User #=  100
AIPS 1: Observ. date=04-FEB-2006     Map date=17-FEB-2006
AIPS 1: # visibilities     43500     Sort order  TB
AIPS 1: Rand axes: UU-L-SIN  VV-L-SIN  WW-L-SIN  BASELINE  TIME1
AIPS 1:            SOURCE  FREQSEL  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       2  -1.0000000E+00       1.00 -1.0000000E+00    0.00
AIPS 1: FREQ       128   6.1400000E+08       0.50 -1.2500000E+05    0.00
AIPS 1: IF           1   1.0000000E+00       1.00  1.0000000E+00    0.00
AIPS 1: RA           1    00 00 00.000       1.00       3600.000    0.00
AIPS 1: DEC          1    00 00 00.000       1.00       3600.000    0.00
AIPS 1: ----------------------------------------------------------------

COL. NO.        1             2              3             4             5
      ROW     FRQSEL     IF FREQ          CH WIDTH      TOTAL BAN     SIDE 
BAND
   NUMBER                Hz               Hz            Hz
        1        1       0.000000E+00     1.250E+05     1.600E+07 
-1

IMAGR1: Beginning channel    1 through    1 with  1 IFs
IMAGR1: GRDMEM: Frequency 6.140625E+08 Hz
IMAGR1: Beginning channel    2 through    2 with  1 IFs
IMAGR1: GRDMEM: Frequency 6.141875E+08 Hz
IMAGR1: Beginning channel    3 through    3 with  1 IFs
IMAGR1: GRDMEM: Frequency 6.143125E+08 Hz
IMAGR1: Beginning channel    4 through    4 with  1 IFs
IMAGR1: GRDMEM: Frequency 6.144375E+08 Hz

  astro5    ISPEC(31DEC05)    100     17-FEB-2006  14:37:55    Page    1
3C286  RA 13 31 08.242  DEC 30 30 31.54  USB.IIM001.1
pixel    coord.value       avg over area
     1    6.13937500E+08    8.0685387E+00
     2    6.13812500E+08    3.2532915E-01
     3    6.13687500E+08    3.9626062E-01
     4    6.13562500E+08    2.7078110E-01

##Work file output of 31DEC05

COL. NO.        1             2              3             4             5
      ROW     FRQSEL     IF FREQ          CH WIDTH      TOTAL BAN 
SIDEBAND
   NUMBER                HZ               HZ            HZ
        1        1       0.000000E+00     1.250E+05     1.250E+05         1


#####Following output corresponds to 31DEC04

The IMAGR frequencies in this case are same as the ISPEC ouput of 31DEC04 
and 31DEC05.

##Work file output of 31DEC04

COL. NO.        1             2               3             4 
5
      ROW     FRQSEL     IF FREQ          CH WIDTH       TOTAL BAN 
SIDEBAND
   NUMBER                HZ               HZ             HZ
        1        1       0.000000E+00     -1.250E+05     1.250E+05 
1
















On Tue, 14 Feb 2006, Eric Greisen wrote:

> I now understand some things better.
>
> TST has had a change from NEW.  The calibration routines used to
> ignore the channel width from the FQ table.  This could be a big
> problem if the channel width from the selected FQID or IF was not the
> same as that in the input header (presumably FQID 1, IF 1).  This
> correction has not been put in 31DEC05.  Thus, the fact that TST got a
> width based on the FQ table while NEW and OLD were based on the input
> header now makes sense.
>
> Also, the FQ reading routines convert the channel width to negative if
> the FQ record has either a negative channel width or a negative
> sideband (and the sideband is then listed as +1).  This explains why I
> always got negative increments in my IMAGR cubes.
>
> I note now that the GRDMEM messages seem to be getting the values from
> the FQ table whether the header does or not - but they still have the
> right sign.  So I still do not understand your result.
>
> Could you run IMAGR so that the work file is saved (set IN2NAME and
> IN2CLASS) and look at the FQ table attached to it?
>
> Eric Greisen
>






-----------------------------------------------------------------------



Neeraj Gupta                       Phone : 91-20-25697107,25691384
NCRA (TIFR),                               office extn. 253
University of Pune Campus, 
Ganeshkhind,                       email : neeraj at ncra.tifr.res.in 
Pune - 411 007
India