ChangeLog of raPatchClosedloop.py v104 - Time shifted polys: for time-shifted ASC polys the behaviour reverts to v102 (remove delay discontinuities). For useable-as-is ASC polys the behaviour remains as in v103 (retain initial delay of each ASC poly segment, re-referenced only once to CALC9). This attempts to remove the small discontinuities (<5ns) that are worsened (5..50ns) due to "incorrectly" extending the delay model of each poly segment beyond its region of validity. While the final model is smoother, it is not more correct either. Which method - if any - works better (v102, v103, v104) when ASC and CALC9 times are not matching needs to be determined experimentally. The optimal approach would be for ASC to always provide polynomial data on a CALC9-consistent time grid. v103 - Clock jumps in the ASC polys are retained; these are typ. <10 nanoseconds between each 60s polynomial segment. Retaining the tiny jumps may be closer to what ASC intended (provided that these jumps exist on purpose in ASC data) - Fixes a corner case when nearest-in-time poly selection is needed (ASC vs CALC9 time range mismatch), namely now the very last poly is not ignored, but is included in the new .im v102 - When there is no ASC poly to match the time range of an DiFX/CALC9 .im poly record, the nearest-in-time ASC poly is used. It is shifted ("extended") into the .im poly time range. Note 1: Time shifting the coefficients will yield a worse model - but still better than nothing. Note 2: Extrapolation/reinterpolation is not possible, because ASC polynomial segments are discontinuous. v101 - Removes clock jumps in ASC polys The first generated .im poly retains the 0th order coeff (delay) from DiFX/CALC9, higher order coefficients are copied from the ASC delay poly file. The second and later .im polys have a 0th order coeff equal to that of the first poly plus the cumulative delay-deltas of each ASC polynomial. - Adds code (unused) for time-shifting of ASC poly coefficients