[daip] Re: odd behavior? in SETJY and UV model subtraction/division

[Eric Greisen]

Samuel Conner writes:
 > Dear Dr. Greisen,
 > 
 >   Thanks for the guidance re: new adverbs. It worked perfectly. I had noticed the "new" (since my last installation in '94) method of importing adverbs into the AU routines, but had not realized that it would work with user defined environment variables. Thank you.
 > 
 > ---
 > 
 >   I have noticed a puzzling behavior in SETJY. I have been calibrating some archival 3C295 data to build a clean model for direct flux scale calibration of some other observations, and I noticed that the SETJY OPTY='CALC' flux for 3C295 varies depending on APARM(2) (C-Band : 4.8663, 4.8163 GHz reported below)
 > 
 > APARM(2)=1
 > localh> SETJY1: BIF =  1 EIF =  2 /Range of IFs
 > localh> SETJY1: '3C295           ' IF =  1 FLUX = 6.5576 +/-  0.5760 (Jy calcd)
 > localh> SETJY1: '3C295           ' IF =  2 FLUX = 6.6339 +/-  0.5820 (Jy calcd)
 > localh> SETJY1: / Using Baars et al or ATCA/PKS (1934-638) coefficients
 >  
 > APARM(2)=2
 > localh> SETJY1: BIF =  1 EIF =  2 /Range of IFs
 > localh> SETJY1: '3C295           ' IF =  1 FLUX = 6.5510 (Jy calcd) 
 > localh> SETJY1: '3C295           ' IF =  2 FLUX = 6.6272 (Jy calcd)
 > localh> SETJY1: / Using (1995.2) VLA or Reynolds (1934-638) coefficients
 >  
 > APARM(2)=3
 > localh> SETJY1: BIF =  1 EIF =  2 /Range of IFs
 > localh> SETJY1: '3C295           ' IF =  1 FLUX = 6.5576 (Jy calcd)
 > localh> SETJY1: '3C295           ' IF =  2 FLUX = 6.6339 (Jy calcd)
 > localh> SETJY1: / Using (1990) VLA or Reynolds (1934-638) coefficients
 >  
 > APARM(2)=0
 > localh> SETJY1: BIF =  1 EIF =  2 /Range of IFs
 > localh> SETJY1: '3C295           ' IF =  1 FLUX = 6.5458 (Jy calcd)
 > localh> SETJY1: '3C295           ' IF =  2 FLUX = 6.6218 (Jy calcd)
 > localh> SETJY1: / Using (1999.2) VLA or Reynolds (1934-638) coefficients
 > c
 > APARM(2)=1 and 3 match, and 2 and 0 are progressively .1% fainter.
 > 
 > I queried Rick Perley as to whether there was a known trend in the absolute brightness of 3C295 and he knew of none. There is a faint core in 3C295, but I don't think that it is bright enough at C-Band to be able to produce this much variation. I'm puzzled. I am proceeding with the pre-1990 values, but I wonder whether this post 1990 trend is intended.
 > 
 > 

   The trend is only in changes to the model that we have used.  We
are working on an improved SETJY in which 3C295 will be constant.  But
the accuracy above is really rather good for almost all purposes.  If
it is reall crucial, consult Bryan Butler (bbutler).

 > -------------
 > 
 > I have noticed, when performing CALIB and UVSUB with a clean component model that has multiresolutions in it, that if specify CMETH='GRID' or '', I get the following error:
 > 
 > localh> UVSUB1: SETGDS: imaging done with reprojected tangent point(s)
 > localh> UVSUB1: FACSET: 7.477910 Jy found from 3488 components
 > localh> UVSUB1: Create 3C286       .UVDIV .   1 (UV)  on disk  1  cno    4
 > localh> UVSUB1: Divide data by model - first compute model by summing
 > localh> UVSUB1: CC FILE NOT ALL ONE TYPE/SIZE
 > localh> UVSUB1: ZOPEN: LUN = 28 ALREADY OPENED IN FTAB
 > localh> UVSUB1: HICREA: CAN'T OPEN HI FILE - ERROR      1
 > localh> UVSUB1: SUBHIS: ERROR  4 COPY/OPEN HISTORY FILE
 > localh> UVSUB1: HILOCT: FILE    28 NOT OPEN IN HITAB
 > localh> UVSUB1: ZOPEN: LUN = 28 ALREADY OPENED IN FTAB
 > localh> UVSUB1: TABCOP: ERROR    1 OPENING NEW FQ FILE VERS   1 TO   1
 > localh> UVSUB1: ZOPEN: LUN = 28 ALREADY OPENED IN FTAB
 > localh> UVSUB1: TABCOP: ERROR    1 OPENING NEW AN FILE VERS   1 TO   1
 > localh> UVSUB1: ZOPEN: LUN = 28 ALREADY OPENED IN FTAB
 > localh> UVSUB1: TABCOP: ERROR    1 OPENING NEW WX FILE VERS   1 TO   1
 > localh> UVSUB1: SUBHIS: ERROR COPYING TABLES
 > localh> UVSUB1: Appears to have ended successfully
 > localh> UVSUB1: localhost    31DEC04 TST: Cpu=       0.8  Real=      10
 > 
 > This does not happen when I specify CMETH='DFT'
 > 
 > It appears to me that the gridded subtraction method does not like it when the CCs are not all the same type and size. This is probably not worth changing as modern machines are fast enough to do DFT subtractions always. But perhaps it would be helpful to users who stumble onto this (neglecting to set CMETH='DFT', as I did) and wonder if somehow their executables have broken (as I did) to include an additional message such as "REDO WITH CMETH set to 'DFT'" or some such. Or, alternatively, CMETH= "" could default to DFT whenever the CC table is incompatible with the current gridded subtraction method.

   The gridded must have the same function for amplitude as a function
of u,v for all components in a CC file.  I have added the extra
message you suggested.

 > 
 >  Thanks for your time. I am conscious that I have been a bit of bother in recent months. I wish to express my appreciation for this package. It is extraordinary. I'm participating in a software packages seminar/class at MIT and will be making a 90 minute presentation/introduction on the AIPS package in mid-April. I will be lavishly praising it and its developers. Thank you.
 > 

Cheers,

Eric Greisen
 >