[daip] 31DEC13 LINUX midnite job (dave, 20140808.185323)

aipsmgr at nrao.edu aipsmgr at nrao.edu
Fri Aug 8 14:54:30 EDT 2014


dave update report for 31DEC13 on Fri Aug  8 18:54:29 UTC 2014 (UT)

Copies and compiles:

AIPSUPD - Using CVS for copying files.
UPDCVS - cvs copy of 31DEC13 begun, 1st character means
 - U added, P updated, M your file differs from master
 - C you have a changed file needing work (error!)
 - ? you have a file not on the master (ignore)
? 31DEC13/ERRORS
U 31DEC13/TIMESTAMP
P 31DEC13/HELP/PCAL.HLP
P 31DEC13/HIST/CHANGE.DOC
P 31DEC13/Q/PGM/NOTST/PCAL.FOR
P 31DEC13/UPDATE/COMLNK.UPD
U 31DEC13/UPDATE/COMLNK.UPD.SUM
U 31DEC13/UPDATE/LASTCVS.DAT
P 31DEC13/UPDATE/PUTBCK.UPD
U 31DEC13/UPDATE/PUTBCK.UPD.SUM
P 31DEC13/UPDATE/REASONS.UPD
U 31DEC13/UPDATE/REASONS.UPD.SUM
UPDCVS - cvs update of 31DEC13 completed
UPDCVS - cvs update of TEXT completed
AIPSUPD - UPDCVS apparently worked

UPDCONTROL - /home/AIPS/31DEC13/LINUX/UPDATE/LASTREMOVE.DAT = 20140627.181032
UPDCONTROL - /home/AIPS/31DEC13/LINUX/UPDATE/LASTCOPY.DAT = 20140627.181032
UPDCONTROL - /home/AIPS/31DEC13/LINUX/UPDATE/LASTCOMRPL.DAT = 20140627.181032
UPDCONTROL - /home/AIPS/31DEC13/LINUX/UPDATE/LASTCOMLNK.DAT = 20140627.181032

UPDCONTROL - Everything seems in order

UPDCOMRPL: COMRPLs


UPDCOMRPL: currently in /home/AIPS/31DEC13/LINUX/UPDATE

UPDCOMLNK: COMLNKs

08-AUG-2014 18:49:41 20140808 NEW QPGNOT   PCAL.FOR      egreisen

UPDCOMLNK: currently in /home/AIPS/31DEC13/LINUX/UPDATE
UPDCOMLNK: /home/AIPS/31DEC13/Q/PGM/NOTST/PCAL.FOR


UPDCONTROL - Reasons for file updates on Fri Aug  8 18:54:23 UTC 2014 (UT)

08-AUG-2014 18:48:00 20140808 NEW HIST     CHANGE.DOC    pcal
08-AUG-2014 18:49:26 20140808 NEW QPGNOT   PCAL.FOR      bad averaging, other lesser fixes
08-AUG-2014 18:49:30 20140808 NEW HLPFIL   PCAL.HLP      initial guess option

CHANGE.DOC entries:


14278.  January 13, 2014            PCAL                 Eric
        Found two places that referred to CATIN using UV header
        pointers that had been recomputed for the header after
        calibration.  Old data sets might have a no longer standard
        axis order and so the two might differ.  This caused it to
        lose an IF when saving the results in a pure continuum case.
14351.  April 20, 2014          polarization             Eric
        PCAL      (a) In IPCALC (solves the ORI- mode), changed it to
                  handle "no data found" gently, since many channels
                  in a row may be flagged.  A message appears and an
                  answer of (0,0) is returned.
                  (b) In LPCALC (solves the simple model), changed it
                  to trap "no data found" and set 0 into the answers
                  rather than going through all the math to end up
                  with 0 anyway.
                  (c) Changed the automatic reading of the previous
                  solution from the AN or PD table into an optional
                  one.  The default is to omit that reading - bad
                  values can hurt much more than starting with the
                  assumed circular polarization.
                  (d) Corrected BIF and EIF back to the user's input
                  for writing in the history file.
        PCAL      Help: added CPARM(7) option to read initial guesses
                  from the AN or PD table or, by default, omit that.
14398.  June 24, 2014               PCAL                  Eric
        PCAL used to quit on 10 consecutive failures.  Bad channels
        may exceed this so changed the limit to 256 consecutive
        failures.  Any one success resets the counter.
14429.  August 8, 2014              PCAL                 Eric
        The data averaging over time code was written seemingly by
        someone (not me!!) who does not understand real data.  It
        assumed that all samples had 4 valid correlations (RR, RL, LR,
        LL) and that a straight average would be better than a
        weighted one.  If the RL and LR were flagged a lot compared to
        either one of RR and LL, then the source polarization would
        appear reduced by this (bad) averaging method, assuming the
        flagged RL and LR values were not crazy.  The weight sums
        included all weights which could have been negative sometimes
        or zero, so any weighting done woth those sums would have been
        questionable at best.
        Moved all to 31DEC13 8-Aug.



More information about the Daip mailing list