[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