[daip] Problem with AIPS

[Eric Greisen]

dbgob at brandeis.edu writes:
 > Eric,
 > 
 > Sorry about the confusion in the message. I have re examined the data  
 > sets, both in the archive and through listr to verify my sources are  
 > there, and they are. The gainuse 3 would only be used after the second  
 > time CLCAL is run. For example:
 > 
 > > task 'clcal'
 > > calcode ''
 > > freq 1
 > > opcode 'cali'
 > > snver 0
 > > interp '2pt'
 > > gainver 1
 > > gainuse 0
 > > snver 1
 > > sour '0742+103''
 > > calsour sour
 > > go;wait
 > CLCAL1: Task CLCAL  (release of 31DEC07) begins
 > CLCAL1: Using interpolation mode 2PT
 > CLCAL1: Copied CL file from vol/cno/vers  1    2   1 to  1    2   2
 > CLCAL1: Deleted     38 records from CL table no.    2
 > CLCAL1: Processing SN table    1
 > CLCAL1: SNMRG: Merging SN table
 > CLCAL1: SNMRG: Write      19 merged records from      19 input records
 > CLCAL1: SN2CL: Applying SN tables to CL table   1, writing CL table  2
 > CLCAL1: Appears to have ended successfully
 > CLCAL1: galaxy       31DEC07 TST: Cpu=       0.1  Real=       0
 > AIPS 1: Resumes
 > AIPS 1: CLCAL    was not found to be running
 > > sour '0740+38''
 > > go;wait
 > CLCAL1: Task CLCAL  (release of 31DEC07) begins
 > CLCAL1: Using interpolation mode 2PT
 > CLCAL1: Copied CL file from vol/cno/vers  1    2   1 to  1    2   3
 > CLCAL1: Processing SN table    1
 > CLCAL1: WARNING: SN table    1 has already been applied
 > CLCAL1: SNMRG: Merging SN table
 > CLCAL1: SNMRG: Write      19 merged records from      19 input records
 > CLCAL1: SN2CL: Applying SN tables to CL table   1, writing CL table  3
 > CLCAL1: SN2CL: WARNING: Will try to append new solutions to CL table   3
 > CLCAL1: SN2CL: This is because there are no entries for specified,
 > CLCAL1: SN2CL: TIMERANGE, SOURCE, SUBARRAY or FREQID in CL table   1
 > CLCAL1: SN2CL: WARNING: NO CL RECORDS WRITTEN

    This clearly states that source 0740+38 does not exist in your
data set - or at least no entries were made for it in the CL table
which would tell me that no entries exist for it in the NX table and
it is not present.  (FILLM writes the NX and CL table together.)


 > The first iteration produces CL 2 for the phase calibrator 0742+103.  
 > The second produces CL 3 for 0740+38, but fails to make anything for  
 > presumably same reason causing problems throughout. Why would saying  
 > source='0740+38','' be problematic? From above you can see that the  
 > exact command was sour '0740+38'' which has never given me any  
 > difficulty in the past.

     That gramar, although incorrect, should not cause trouble and I
did not imply that it did.  Simply asking for this particular source
in this particular data set is the casue of difficulties.

 > As for trying to run uvplt, after reading in the data, any step taken  
 > after my CALIB task would make running UVPLT for 0740+38 impossible  
 > unless I did a restore 0. For example, I could reset all the UVPLT  
 > adverbs to default (save dotv 1 to print to screen, and sour  
 > '0740+38'' to specify source) and it would claim there were no data  
 > points, regardless of whether I was calling for CL table 1, 2, or 3,  
 > or even asking it to use them via DOCAL -1 or 1.

    RESTORE 0 is not some magic incantation.  It resets all adverbs to
default values - of relevance to you the adverbs to GO and to UVPLT.
DEFAULT GO and DEFAULT UVPLT would do the same.  UVPLT is failing
because some adverb to it is asking for something that does not work
on your data set.

    I suggest looking at your data set in more detail, esp the problem
source.  VPLOT requires a time axis and, if the one source has only
one time, then it may complain about it for that reason.

If you absolutely insist I can look at your data set for you but no
one has changed these tasks in some way  to descriminate against one
10-minute scan of yours.

Eric Greisen


 > 
 > I can forward you the data set if you like. Unless I am missing  
 > something completely obvious, you will see the same results almost  
 > immediately. Since this data set is being pushed through the same  
 > pipeline as all the other sets I have been working with, it should  
 > function just fine.
 > 
 > Try this perhaps:
 > 
 > clrmsg
 > restore 0
 > 
 > task 'fillm'
 > infile 'fits:AO105_'
 > indi 1
 > outseq 0; outdi 1; DOUVCOMP -1; DOALL 1
 > DOCONCAT 1; ncount 1; nfile 0
 > go;wait
 > 
 > infile ''
 > task 'listr'
 > docrt 132
 > optype 'scan'
 > go prtan
 > refant 25
 > getn 1
 > zap:wait
 > getn 2
 > 
 > task 'uvflg'
 > sour '0742+103''
 > anten 9
 > baseline 25
 > bif 1
 > eif 1
 > timer 00 21 02 50 00 21 03 00
 > go;wait
 > 
 > anten 0
 > baseline 0
 > timer 0
 > task 'uvplt'
 > dotv 1
 > go;wait
 > 
 > sour '0740+38''
 > go;wait
 > 
 > task 'setjy'
 > stokes ''
 > uvrange 0
 > timer 0
 > antenna 0
 > baseline 0
 > bif 1
 > eif 2
 > optype ''
 > sour '0742+103''
 > zerosp 3.30 0 0 0
 > go;wait
 > 
 > task 'calib'
 > freq 1
 > aparm 0
 > aparm(6) 2
 > cparm 0
 > cparm(5) 1
 > solmode 'a&p'
 > minamper 10
 > minphser 10
 > calsour sour
 > go;wait
 > 
 > task 'uvplt'
 > 
 > sour '0740+38''
 > go;wait
 > 
 > You can note that UVPLT will have all the same entries throughout as  
 > they should not change save which source you are looking at. After  
 > completing CALIB if you try to plot 0740+38 it gives:
 > 
 > UVPLT1: Task UVPLT  (release of 31DEC07) begins
 > UVPLT1: UVGET: Using flag table version   1 to edit data
 > UVPLT1: FOUND    0 POINTS: NOT ENOUGH TO SELF-SCALE
 > UVPLT1: Purports to die of UNNATURAL causes
 > UVPLT1: galaxy       31DEC07 TST: Cpu=       0.0  Real=       0
 > AIPS 1: Resumes
 > 
 > But trying to plot 0742+103 in UVPLT works perfectly:
 > 
 > > sour '0742+103''
 > > go
 > UVPLT1: Task UVPLT  (release of 31DEC07) begins
 > UVPLT1: UVGET: Using flag table version   1 to edit data
 > AIPS 1: Resumes
 > > UVPLT1: PLTUV:      20857 Points plotted
 > UVPLT1: Appears to have ended successfully
 > UVPLT1: galaxy       31DEC07 TST: Cpu=       0.4  Real=       1
 > 
 > You will also note that task VPLOT will not work for 0740+38 at any point.
 > 
 > Hopefully this more coherent email will help. My profuse apologies for  
 > the confusion in the first email.
 > 
 > ~Doug
 > 
 > 
 >