[daip] a FILLM problem

[Data Analysts]

----- Begin Included Message -----

>From s.kurtz at astrosmo.unam.mx Wed Oct 10 20:25 MDT 2001
From: s.kurtz at astrosmo.unam.mx
Date: Wed, 10 Oct 2001 21:25:23 -0500
To: analysts at zia.aoc.NRAO.EDU
Subject: a FILLM problem
Content-Type: text
Content-Length: 6022
X-Lines: 149
Status: RO

Dear Analysts,

Hi.  I have a problem....
Sorry to bother you with it, but i'm a bit stumped.

You all loaded some data on for me a few days ago, and I'm having trouble
accessing some of it.  I'll try to give all the relevant information that
I can think of:

The data I had here originally (FILLed with cparm(8)=0) was evidently 
FILLed originally with a 15OCT97 AIPS release.  (I have both the 15OCT98 
and 31DEC01 versions installed here, and the new file that you sent seems
to behave the same way with either version.)

The FILLM of my version of the file was:

FILLM OUTNAME='15/09/97    '   OUTCLASS='CH 0  '
FILLM OUTSEQ=    6   OUTDISK=  2
FILLM  INTAPE =  1, NFILES =   12
FILLM  BAND = 'Q', QUAL =     0,  CALC = '     '
FILLM  VLAMODE ='  '
FILLM  / Control program ID =
FILLM  / VLA conf. = C
FILLM  / correlator mode = 1A
FILLM  / AP options = H
FILLM /TIMERANG = beginning to end
FILLM  BCHAN =    1 ECHAN =    1 / Spectral channels
FILLM  CPARM(1) =  0.000 / Integration (sec)
FILLM  CPARM(3) =   3. / Max. IF stat. to pass
FILLM  CPARM(4) =   0. / .lt. 0 => no shadow flag
FILLM  CPARM(6) =   1. / Subarray
FILLM  CPARM(7) =     0.000 / FQ entry tolerance
FILLM  CPARM(8) =   5.00 / CL table time increment
FILLM  / Telescope = VLA      Program = AK443
FILLM  RELEASE = '15OCT97 '

Whereas the FILLM of the file you sent me was:

FILLM OUTNAME='AK443.970915'   OUTCLASS='CH 0  '
FILLM OUTSEQ=    2   OUTDISK=  3
FILLM  INTAPE =  2, NFILES =   12
FILLM  BAND = 'Q', QUAL =     0,  CALC = '     '
FILLM  VLAMODE ='  '
FILLM  / Control program ID =
FILLM  / VLA conf. = C
FILLM  / correlator mode = 1A
FILLM  / AP options = H
FILLM /TIMERANG =    0/01:33:60.00 to    0/09:36:00.00
FILLM  TIMERANG =   6.527778E-02  4.000000E-01  / days
FILLM  BCHAN =    1 ECHAN =    1 / Spectral channels
FILLM  CPARM(1) =  0.000 / Integration (sec)
FILLM  CPARM(3) =   3. / Max. IF stat. to pass
FILLM  CPARM(4) =   0. / .lt. 0 => no shadow flag
FILLM  CPARM(6) =   1. / Subarray
FILLM  CPARM(7) =     0.000 / FQ entry tolerance
FILLM  CPARM(8) =   0.17 / CL table time increment
FILLM  CPARM(9) =   0.00 / TY table time increment
FILLM  / Telescope = VLA      Program = AK443
FILLM / Weighted with nominal sensitivities
FILLM / Data not compressed, no loss of weight info
FILLM  RELEASE = '31DEC01 '

So the input parameters seem to match up quite well (except that as
per my request you used cparm(8)=0.17.  But there have almost certainly
been some changes in FILLM since 1997 and 2001, so maybe having the same
input parameters is not that important.

BUT, the LISTR scan summaries are different. 
I'll send those as separate files, so as not to make this email too
horribly long or wide.

My old version of this file had 215,732 visibilities and everything was
given FREQID 1.  The version that you FILLed just now has 176,658 visib,
and there are 4 different FQIDs.

Also, if you compare the two LISTR outputs, 
If that's all the more difference there was, i'd just go ahead and use
the file, and take the 18% hit in visibilities.
BUT, there are some other differences as well.
For example, if you compare the two LISTR outputs, starting at scan 34
they differ in terms of what source was being observed.  The time is 
exactly the same, but the source name is different!
What it seems to have done is not load the calibrator in the version 
that you sent.

Comparing my observe file with the two LISTR outputs, what i find is:

OBS FILE		LISTR of OLD FILE	LISTR of NEW FILE
--------		-----------------	-----------------
1) ngc6334f		ngc6334			ngc6334f
2) fast switch on	18033/17302		18033/17302
   18033-21380 using
   1730-130 as calib
3) fast switch on       18075/17302		18075 but NOT 17302
   18075-19565 using
   1730-130 as calib
4) fast switch on	18089/17302		18089 but NOT 17302
   18089-17322 using				
   1730-130 as calib


for items 3) and 4), in the new file that you sent me the two sources
18075 and 18089 are mixed together, although in truth, 18089 wasn't 
observed until 18075 was all finished.  This zone is most notable in
the scan summary because in the version from my old file scans 36-52
have calibrator code A scans mixed in, and in the listr output from
the new file those calcodes are missing in the same scan range.
This is not to suggest that the earlier file was alright: it's missing
a bunch of data that showed up in the file just loaded this week.
However, that data in particular was not of great interest to me so
i wasn't too worried about it.
By checking the observe file i see that the sequence of data should
actually be:

NGC6334F  in sequential scans, followed by fast-switching on:
18032-21379 nod 17302-13028
18075-19565 nod 17302-13028
18089-17322 nod 17302-13028
18039+01088 nod 17302-13028
18111-18543 nod 17302-13028
18175-16128 nod 17302-13028
19111+10484 nod 19238+21004
plus about a 8 more...

Also, i would note that the difference in visibility numbers is NOT
solely due to some data not being there.  As you'll note from the LISTR
output, practically all scans have slightly different numbers of 
visibilities.  I checked a couple of them and couldn't find anything
obvious, like one antenna missing for the more recently FILLed data.

Based on all the stuff above, i guess maybe it has something to do
with the FREQID and the slightly different frequencies at which the
same calibrator was observed.
But *if* that is the problem, i still don't see how it could have
happened, because both times FILLM was run, cparm(7) was 0, according
to the history file.  But maybe this is a difference between the two
versions of AIPS that were used?

The help file for FILLM says that for spectral line cparm(7)=0 should
load all data with the same FQ number.  But is the channel 0 file 
treated as spectral line or continuum?  Possibly the problem could
be solved by setting cparm(7) to some large number?

Anyhow, hopefully this is something you've seen before and you'll
know right off what happened, w/o wasting a lot of time on it.

thanks very much!
best regards,
stan


----- End Included Message -----