[daip] MOJAVE BL149BE 512 Mbps problems summary

[Eric Greisen]

Yuri Y. Kovalev wrote:
> Dear Amy,
> 
> I continued working on BL149BE and summarize here my experience and 
> suggestions. I hope that it will help to improve AIPS support of 
> 512 Mbps (2-pass) VLBA experiments.
> I use 31DEC08 AIPS version on an MPIfR server.
> 
> 1. VBGLU has produced artificial amplitudes for FD-OV baseline after 
> gluing AIPS-friendly FITS files. You have confirmed this problem.
> I solved it by using FITS-IDI files (vlbaload, vlbafix, VBGLU).
> In this way no artificial amplitudes are produced.
> However, one FITS-IDI file seemed to be corrupted.
> AIPS was unable to read it in.
> This is BL149BE FITS IDI file VSN005549_file40
> This file is very small, only 115200 Bytes.
> * I suggest to delete this file from the NRAO archive.
> 
> 2. I have a general comment on the current realization of vlbafix.
> For some reason, it applies FG table.
> * I suggest not to apply FG table, to keep the uv data and the table 
> while doing vlbafix. This would give users much more flexibility, FG 
> table can be conveniently applied at any later moment.
> 
> 3. VBGLU had more problems, unfortunately.
> (i) It was unable to produce AT table with the following message:
> GLUTAB TABLE: AT MISSING REQUIRED COLUMNS, FILE 1
> * Could you please take a look at this problem?
> (ii) CQ table was produced (merged) absolutely incorrectly with 
> artificial numbers all over the table.
> (CQ tables were fine in FQ-1 and FQ-2 files after vlbafix.)
> You can find the corrupted table as ASCII-OUT attached to this e-mail.
> * Could you please take a look at this problem?
> 
> 4. PC table data turned out to be useless, but nothing can be done 
> about it. Thanks to Leonid Kogan for explanations.
> 

I have discovered the cause of the VBGLU troubles.  The wrong UV data 
arose when the data files are not in strict TB order (usually they are 
in T? order with the Baseline values in various orders).  The error was 
a stupid mis-addressing that took place when the I/O had to be restarted 
to get a record that preceded the current buffer.  The error with the AT 
file has been bypassed and the handling of character strings was 
corrected for all files especially the CQ table.  A MNJ on 31dEC08 on 27 
December or later will repair VBGLU.

I believe the choice of flagging in VLBAFIX was made because the initial 
VLBA FG table is very large and a significant reduction in the size of 
the data set is obtained as well as a reduction in the complex FG table 
logic that must be done for all data with large numbers of flags.  The 
data flagged on input is of no value and you should not desire to keep it.

Eric Greisen