[daip] MOJAVE BL149BE 512 Mbps problems summary

[Amy Mioduszewski]

Hi Yuri,

I was on vacation and left VBGLU in Eric's hands, I am glad he found the problem.

As for VLBAFIX, it is a intended to be as simple as possible.  VLBAFIX in fact 
is a conglomeration of VLBASUBA, VLBAFQS, VLBAFPOL and VLBAMCAL.  If you don't 
want flagging then you should run these (except for VLBAFQS, which does the 
UVCOP/flagging) and run UVCOP on your own without the flagging.

Amy

Yuri Y. Kovalev wrote:
> 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
>>
>>
> 
> _______________________________________________
> Daip mailing list
> Daip at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>