[evlatests] Misc. upchuck from testing.

Vivek Dhawan vdhawan at nrao.edu
Sun Mar 7 16:43:39 EST 2010


0. Apology: I looked at the WIKI and saw quite a bit of overlap with
    these items, but no way to map tham on - e.g. did not see how to add
    stuff to an item (the 'ATTACH' button seemed to add to the list,
    how do I add to an existing item? 'EDIT' seemed to be a global edit)

1. AIPS:  FRPLT showed 11s period, not real. Traced to binning problem,
    caused by real*4 time precision. Fixed by Eric & tested good.

    https://help.nrao.edu/index.php?_m=tickets&_a=viewticket&ticketid=97


2. AIPS: UVW and UVFIX. Since we are skeptical of everything including Mom
    & apple pie, I used UVFIX to recalculate the UVW in AIPS and compare to
    the incoming set from CASA/exportuvfits.

    a. FIXVIS in CASA (thanks Steve) returns identical UVW to those within
       the MS, and identical to those exported and reaching AIPS.

    b. AIPS UVFIX on EVLA data (last week at least) should be run not with
       defaults, but with tiny but non-zero time change. To compare UVFIX
       with the FIXVIS, i ran it with 10^-6 time offset and differential
       aberration turned off. The changes it makes are then smaller than
       changes made with any other parameter inputs, and are delta UVW
       ~300 ppm, 0.03%.

       The same test done on a VLBA dataset (thanks Leonia) gives ~few ppm.
       So - no panic, but it would be nice to understand where this comes
       from, and if/when we need it better.

       I do not believe UVFIX is necessary for users now.

    c. While checking this, the RAAPP and DECAPP were re-discovered to be
       set to 1858. Again not of interest to users unless they change
       RAAPP/DECAPP in CLCOR, when it will be quite wrong.

    d. I have not investigated whether the frequency (e.g. 1/2 pixel)
       or time labels (e.g. beginning, middle or end of integration)
       have any bearing on the error.

    e. Eric is pondering how AIPS should read/interpret the things it gets
       in its header and antenna tables

    f. There was a recent discussion I believe on IAT/UT etc, I dont know
       the fallout from that (Michael?)


3. HARDWARE / M&C : Set and Remember test, about 2hrs on 55257.068 =March2.
    OSRO-1 mode = 4stokes in 2 subbands, one each AC & BD, 64ch/sb.
    Cycle every minute L,C,X,K bands; same setting at each band, one source.

    The goal was to see if the gain set in the first scan is remembered and
    used throughout the run.

    A lot of unpretty things are excited by the band changes. There are
    (3 bands *24 antennas * 2IF * 2 pol) so a lot of quirks to summarize.
    L band was full of RFI and I have enough to say, so I set it aside.

    Brief summary: a few antennas clearly not returning to the same phase
    when they return to the same band, e.g. ea3 and 6 have several phase
    & amplitude jumps in the 2hours. 13,14,16 (old hardware) have more trouble
    than the newer ones.

    Amplitudes appear better behaved than the phases. Calibration transfer on
    most antennas is clearly worse at X,C,K, compared to the same band observed
    without cycling (e.g. in the WIC loops). X band is worse than the others,
    as Barry already noticed. The errors are typically upto 5% amplitude, 20deg
    phase, and not that much worse at K - i.e. not scaling with sky frequency.

    Not every antenna is bad, there are a few good ones e.g. 2,4,8. I speculate
    that apart from the obvious L302 problems on e.g. 3, this may be caused in
    things like switches that select bands for downconversion in the T304.

    I hope to show plots to experts in the 4pm Monday meeting. I'm at the VLA
    for a tour Monday morning.


4. AIPS: UVFLG on shadowed antennas. A bug was reported (James Miller-Jones?)
    and fixed. I tried it after the fix and have doubts its actually working.
    People should test it. I'll send some details to the AIPS helpdesk ASAP.


5. AAT: Archive access tool - if many files are requested in a single session
    by a single user, they queue up. Multiple requests by the same or several
    users compete for the CPU. Multiple requests for the same file can jam up.
    If a user asks for UVFITS, the intermediate MS is not saved, so re-gets are
    common. These and other gotcha's are being looked at by John Benson, who
    can e.g. do the conversion as soon as an SDM accumulates, and put the
    results into /home/e2earchive/evlatest/  so all users can just go there.
    (assuming the default MCAF etc are what they want.)

V.






More information about the evlatests mailing list