[daip] AIPS question

[Bill Cotton]

Eric,

   Thanks.  The images in question, at least in my test, never went
through FITS but only existed as AIPS files.  The KLNBLK(KIITY)
parameter, however, never gets set.  Where does it live?  
   So far, I only support the equivalent of DO3DIM=TRUE so haven't
worried about keeping track of this.  The old DO3DIM=FALSE was a bad
idea but the new, improved one is something I've been considering.  If
you can really line up the pixels this gives you several things:
1) "Flatten" becomes trivial as well as avoiding the subtle problems
with surface brightness vs. peak brightness conservation.
2) It would be possible to save meaningful CLEAN components,
3) This could fix the performanence problem of 3D imaging/clean (one
facet at a time).

   Speaking of performanence, I recently became aware of how truly
expensive the sine/cosine calls in the DFT modeling really is.  I've
got an approximate routine that runs 8 times faster than sin+cos
calls; in a simple UVSub test, the whole thing (in "DFT" mode") ran 3
times faster, in spite of having to select and calibrate the input.
There's a draft writeup in
ftp://ftp.cv.nrao.edu/NRAO-staff/bcotton/Obit/FastSine.pdf. Since this
doesn't require third party software, you could implement it in AIPS.
It does require some additional c compiler options to use the "hidden"
(no shit) vector machine in each intel/AMD chip.  The video game
people have amazing influence.

-Bill

Eric Greisen writes:
 > Bill Cotton wrote:
 > > Eric,
 > > 
 > >    One of my users was having a problem using the combination
 > > Imager+CALIB+CLCAL (Imager in Obit, CALIB,CLCAL) in AIPS.  When he did
 > > this on a calibrator and reimaged it, it moved one pixel to the right.
 > > I've confirmed this behavior and that Imager+Calib+CLCal (all in Obit)
 > > does the right thing.  Also, the position in the CC table for the
 > > calibrator was (0,0) and the reference position in the header correct.
 > > I claim this should always give the desired results.
 > >    I suspected that the difference in which pixel is the reference was
 > > causing trouble, (nx/2,ny/2+1) in AIPS, (nx/2+1,ny/2+1) in Obit.
 > > I've traced the problem to the following segment in GRDAT.FOR:
 > > C                                       Get reference pixel offsets from
 > > C                                       tangent point
 > >       IF ((KLNBLK(KIITY).EQ.1) .OR. (KLNBLK(KIITY).EQ.2)) THEN
 > >          XPOFF(JFIELD) = CLNR(KRXPO)
 > >          YPOFF(JFIELD) = CLNR(KRYPO)
 > >       ELSE
 > >          XPOFF(JFIELD) = (CLNR(KRCRP+IRAOFF) - KLNBLK(KINAX+IRAOFF)/2)
 > >      *      * CLNR(KRCIC+IRAOFF)
 > >          YPOFF(JFIELD) = (CLNR(KRCRP+IDECOF) - KLNBLK(KINAX+IDECOF)/2 -
 > >      *      1) * CLNR(KRCIC+IDECOF)
 > >          END IF
 > > What, exactly, is this doing?
 > 
 > My memory is a bit hazy - but one needs the phase shift parameters in 
 > order to subtract the components from the correct location.  All images 
 > made bu AIPS will have KIITY set to 1 (do3d false) or 2 (do3d true) so 
 > that the shift - XPOFF and YPOFF used all over the code that you 
 > initially wrote - will be correctly known.  It is "hidden" in an aips 
 > history card which FITTP writes and IMLOD reads.  The "center" of the 
 > image comes in to some of the handling of the CC files for reasons I 
 > could probably figure out if I took it to be important enough to spend a 
 > couple of days.  The image creation routines set up
 > 
 >        IF (DO3DIM) THEN
 >           CATBLK(KIITY) = 2
 >           CATR(KRXPO) = 0.0
 >           CATR(KRYPO) = 0.0
 >        ELSE
 >           CATBLK(KIITY) = 1
 >           IF (IFIELD.LT.1) THEN
 >              CATR(KRXPO) = 0.0
 >              CATR(KRXPO) = 0.0
 >           ELSE
 >              CATR(KRXPO) = (CATR(KRCRP) - ICNTRX(IFIELD)) * CATR(KRCIC)
 >              CATR(KRYPO) = (CATR(KRCRP+1) - ICNTRY(IFIELD)) *
 >       *         CATR(KRCIC+1)
 >              END IF
 >           END IF
 > 
 > I can see where confusion will come when the Clean image has an odd (in 
 > AIPS) ref pixel but no shift and no evidence in the header to cover this 
 > information.
 > 
 > Looks like another place where the difficulty of popping back and forth 
 > between packages is further revealed.  XPOFF is all over QCLEAN from the 
 > early 1990's.  I think I hit trouble trying to use subimages for models 
 > and that may be when I started to record these data for recovery later.
 > 
 > Eric