[daip] MOJAVE BL149BE 512 Mbps problems summary

[Yuri Y. Kovalev]

Dear Eric,

Many many thanks!! That was quick!

Re. flagging while doing vlbafix.
Unfortunately, sometimes one needs to unflag data which are flagged in 
the initial FG table. For an example, I could refer to the following:
"HN data flagged due to ellipsoid disconnect; data OK." in
http://www.vlba.nrao.edu/astro/VOBS/astronomy/apr08/bk151/sniffer/BK151.20080407.sniff
or "NL ellipsoid, false flagging of data" in
http://www.vlba.nrao.edu/astro/VOBS/astronomy/may08/bl149ai/bl149ailog.vlba
or "NL ellipsoid falsely flagging data." in
http://www.vlba.nrao.edu/astro/VOBS/astronomy/jul08/bl149ak/bl149aklog.vlba
I got a recommendation from NRAO analysts to unflag such data.
If I use the suggested vlbaload, I would be unable to do it.

Sometimes I need to understand why there is no data for certain scans at 
telescopes which are claimed to be OK in logs. E.g., in recent BK150D a 
"Subreflector error" flag was flagging out some scans with no indication 
of such a problem in logs. I unflagged it and got important telescope 
back (SC) for a scan on a bright calibrator. Even if the amplitude is a 
bit off (it was not at C band), I successfully used it as a calibrator 
for phase, crosspol, bpass.

I would suggest not to apply FG in vlbaload.
Another way would be to make it as an additional parameter for
vlbafix -- apply or not apply FG table.

I had a similar discussion half a year ago about AIPS friendly fits 
files which are provided by the NRAO archive. As of now, as far as I 
see, they are provided with the FG table, uv data are not flagged out 
initially.

With best wishes and thank you again!
Yuri.

On Fri, 26 Dec 2008, Eric Greisen wrote:

> 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
> 
>