[daip] Amplitude calibration of VLBI data

[Jim Ulvestad]

Okay, improving APCAL has been on our list for a while, so we'll
add your suggestion to Amy's list to look at when she returns.

Jim

Steven Tingay wrote:

>Hi Jim,
>
>Thanks very much for your quick response, it is much appreciated.
>
>However, after puzzling over the problem for the rest of the day 
>yesterday, Shinji and I sorted it out and now understand what's going on.
>
>The root cause was not a problem with AIPS or a problem with our FITS 
>file.  The root cause was the different definitions of the (x,y,z) 
>coordinate system that describes antenna positions used by the ATNF and 
>NRAO.  The mismatch in the definition leads APCAL to think that the source 
>is below the horizon for most of the observation, meaning that SN table 
>solutions are not generated for these times.
>
>Negating all the y coordinates in our antenna table, to become consistent 
>with the definition used in AIPS, solved the problem immediately.
>
>So, when generating our FITS file we will have to be mindful of the 
>coordinate system we use for our antenna table, depending on if we want to 
>reduce our data in MIRAIAD (ATNF definition) or AIPS (NRAO definition).
>
>One comment though.  It would be nice, and not difficult to implement, if 
>APCAL reported reasons why it does not generate SN table solutions during 
>runtime.  For example, a message saying "No SN table entry generated: 
>source below horizon" would have saved an enourmous amount of time in 
>chasing down this problem.  Perhaps this could be added to APCAL?
>
>Again, thanks for your email, but I'm glad we found the problem before it 
>got added to your "things to do" list.  
>
>Cheers, Steven   
>
>##=====================================================##
>Dr Steven Tingay		stingay at astro.swin.edu.au
>Swinburne SKA Project Leader
>Associate Professor
>
>Centre for Astrophysics and Supercomputing
>Swinburne University of Technology
>Mail No H39
>P.O. Box 218, Hawthorn, Vic. 3122, Australia
>
>ph:  +61 3 9214 8758
>fax: +61 3 9214 8797
>
>http://astronomy.swin.edu.au/ska
>##=====================================================##
>
>On Thu, 8 Dec 2005, Jim Ulvestad wrote:
>
>  
>
>>Hi Steven,
>>
>>Could you send us the following?
>>
>>(1) FITS file of your complete set of tables, with TASAV, and an e-mail
>>telling
>>us which is which.
>>(2) Your input file for ANTAB.
>>(3) Your AIPS inputs for ANTAB and APCAL.
>>(4) A snippet of data created with UVCOP, say 10 minutes or so from the
>>start of the run.
>>
>>Easiest thing is probably to put them on an ftp site or something.  We
>>suspect any one of a number of problems, such as subtle errors in the
>>input text file, problems with polarization labeling, or minor input errors.
>>At least we can try to rule those out before worrying about the structure
>>of the FITS file.
>>
>>Amy Mioduszewski normally handles our VLBI problems, but she's on
>>vacation.  Since I have another "job," you may need to be a little patient!
>>
>>Please reply to daip, not just to me.
>>
>>Cheers,
>>
>>Jim U.
>>
>>Steven Tingay wrote:
>>
>>    
>>
>>>Dear AIPS help,
>>>
>>>I wonder if you might have some suggestions to help me with a problem I am
>>>having producing amplitude calibration tables for a VLBI dataset.
>>>
>>>The data are from three Australian antennas, correlated on a software
>>>correlator that we have developed here at Swinburne.  The root cause of
>>>our problems may well be the FITS files that we are producing.  However,
>>>we have calibrated data from our correlator before and it worked fine.
>>>And I can't spot anything obvious that is wrong with this particular
>>>dataset.  It seems somthing more subtle is going on.
>>>
>>>Here is a basic synopsis of the problem, the things I have tried, and a
>>>few questions along the way:
>>>
>>>1. Without applying any amplitude calibration data, we can load and 
>>>examine the data, fringe-fit it, export it, and image it.  Data are
>>>present for all expected antennas, in the right time range, and with
>>>the right polarisations/IFs (examining the data with PRTUV, LISTR,
>>>UVPLT, POSSM etc)
>>>
>>>2. I can load the calibration file in the KEYIN format which contains the 
>>>Tsys measurements and gains for each of the three antennas, using ANTAB
>>>- it reads the three gain entries and all Tsys values.  I can
>>>examine the Tsys data in the resultant TY table in SNPLT and it looks
>>>fine, correct values in the correct time range to match the uv data.
>>>As far as I can tell, using PRTAB, the resultant GC table also looks
>>>fine.  Is there a better way to look at the contents of the GC table
>>>than simply using PRTAB?
>>>
>>>3. I ran APCAL to produce an SN table from the TY and GC tables.  That is 
>>>when things go wrong.  APCAL seems to run fine, but when I use SNPLT to
>>>examine the amplitude corrections in the resultant SN table, only two
>>>of the antennas have values in the SN table.  The data for the third
>>>antenna is missing and seems to have not made it through APCAL.
>>>
>>>4. Previously we had a similar problem when the source coordinates 
>>>recorded in the FITS file were wrong and APCAL did not write solutions
>>>for a set of antennas because the source was deemed below the horizon.
>>>However, we fixed that problem and all worked perfectly.  Is there any
>>>other similar sort of issue that may be causing the problem I have just
>>>described?  The source coordinates seem correct, the antenna positions
>>>and mount types seem correct.  Is there something else perhaps that I
>>>should be checking?
>>>
>>>5. I guess I've also seen this problem when an observation has sparse Tsys 
>>>measurements and the measurements don't coincide with the times of
>>>unflagged data.  This should not be the case here.  Tsys measurements
>>>were made every few seconds and very little uv data scans are flagged.
>>>There are both dense Tsys data and uv data.
>>>
>>>6. I briefly tried using ANCAL to read the calibration file and produce a 
>>>CL table directly.  ANCAL complained about the format of one of the
>>>Tsys entries but I could not see any problem that that entry in the
>>>file or those around it.  So, I gave up on ANCAL.
>>>
>>>Thanks for any advice you can give.
>>>
>>>Cheers,
>>>
>>>Steven
>>>
>>>##=====================================================## Dr Steven Tingay
>>>stingay at astro.swin.edu.au Swinburne SKA Project Leader Associate Professor
>>>
>>>Centre for Astrophysics and Supercomputing
>>>Swinburne University of Technology
>>>Mail No H39
>>>P.O. Box 218, Hawthorn, Vic. 3122, Australia
>>>
>>>ph:  +61 3 9214 8758
>>>fax: +61 3 9214 8797
>>>
>>>http://astronomy.swin.edu.au/ska
>>>##=====================================================##
>>>
>>>_______________________________________________
>>>Daip mailing list
>>>Daip at listmgr.cv.nrao.edu
>>>http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>>>
>>>
>>>      
>>>
>>    
>>
>
>_______________________________________________
>Daip mailing list
>Daip at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>  
>