Subject: Re: 32m pointing 
From:    "Kazimierz Borkowski"
Date:    We, February 10, 2010 14:47 

Dear Patrick,

(...)

In my work with these data I never used meteo data, but they are
there almost ready to use. They are described here:

MeteoSince2000.htm

and 1-hourly data are downloadable from here:

Mean01A-final.zip

(...)  First however have a look at appended two ASCII files,
of which one contains the pointing measurements and the other a small 
source catalogue with source names and J2000 equatorial coordinates 
(RA and Dec in degrees) only.

The pointing data are those Roman Feiler has extracted for me from
a larger data set, except that at the outset I removed obviously
corrupt records and tagged some records with a # at the line beginning.
These come only from Autumn 2006. Many columns in it are not useful.
Here is a list of columns (an asterix marks data of interest)
 1. source, *
 2. fname,
 3. az, *
 4. el, *
 5. elOff, *
 6. elAmpl,
 7. azOff, *
 8. azAmpl,
 9. azNoff,
10. azNAmpl,
11. src2cal,
12. cal,
13. data&time, *
14. naz,
15. nel.

The offsets from demanded positions (col. 5 and 7) were obtained
by a fit to cross-scans so that the coordinates are not reliable.
This worried me once, but soon I found that these coordinates are
really not so important for me, for (1) the offsets do not change
rapidly, (2) I know the demanded Az and El as determined by telescope
location and time. So in fact in my calculations I do not use them
at all and would like to warn you against possible troubles if you
would rely on them too heavily. The measured offsets are in degrees.

(...)

Subject: RE: 32m pointing From: "Patrick Wallace" Date: Th, February 11, 2010 23:38 To: "'Kazimierz Borkowski'" (...) > This dependence on weather might be significant at lower > elevations, so if you think so, please do write back a few > words about this. The following table shows the amount of refraction at Torun for three different sets of conditions: Refraction at Torun, 30 GHz Weather 1 = 1000.0 hPa -10.0 C 30.0 % Weather 2 = 1000.0 hPa +30.0 C 90.0 % Weather 3 = 950.0 hPa +30.0 C 90.0 % el 1 2 3 90.00 0.00 0.00 0.00 85.00 1.50 2.07 2.00 80.00 3.02 4.16 4.03 75.00 4.59 6.33 6.13 70.00 6.23 8.59 8.33 65.00 7.98 11.01 10.67 60.00 9.88 13.63 13.21 55.00 11.98 16.53 16.01 50.00 14.36 19.80 19.19 45.00 17.10 23.59 22.86 40.00 20.37 28.09 27.23 35.00 24.39 33.64 32.60 30.00 29.54 40.75 39.49 25.00 36.50 50.36 48.81 20.00 46.59 64.29 62.31 15.00 62.77 86.69 84.02 10.00 93.32 129.11 125.18 9.00 102.98 142.59 138.27 8.00 114.69 158.97 154.17 7.00 129.14 179.26 173.88 6.00 147.34 204.95 198.85 5.00 170.81 238.35 231.35 4.00 201.94 283.18 275.02 3.00 244.48 345.61 335.96 2.00 304.56 436.42 424.85 1.00 392.12 574.96 561.04 deg mdeg mdeg mdeg Subject: RE: 32m pointing From: "Patrick Wallace" Date: Su, February 14, 2010 10:44 Hi Kaz, I have transformed your pointing file into a form that TPOINT can understand, and have some reasonably convincing modelling results to show you. The all-sky pointing I get is about 6 mdeg RMS. Of course, only part of this is the antenna performance itself; the figure is a combination of three things: 1) The known deficiencies of the 32m TCS (that it neglects aberration, UT1-UTC and refraction) affect the logged pointing data. On the basis of the one spot check we did, my simulation of the 32m TCS errors is incomplete at about the 2 mdeg level. There is in addition the fact that I have used fixed values for pressure, temperature and humidity. 2) The noise in the individual observations; i.e. what scatter you would see if you repeated the same observation several times. 3) The innate repeatability of the 32m antenna (i.e. the ultimate performance limitation). In the future, (1) can be eliminated by installing improved algorithms in the TCS, and from the look of the residuals I'd expect (2) to be at least as large as (3). With improved absolute pointing, so that your cross scans start with the source already centred to a fraction of a beamwidth, I would expect (2) to decrease significantly. Notes on the data conversion process: * Although I have made provision for UT1-UTC when predicting the true direction, the observations happen to be from a period of a few weeks when UT1-UTC was small and changed by less than 0.1s (from 0.15s on 2006/9/22 to 0.06s on 2006/12/12). I have therefore ignored it, for now. * I had to interpret your "elevation offsets" as "zenith distance offsets", in order to comply with your stated encoder-minus-sky sign convention. When I let TPOINT do a hands-off automatic fit, it produced the following model (unit is arcsec): coeff value sigma 1 IA -55.31 11.497 2 IE +96.58 3.233 3 & HASA -10.85 2.504 4 & HACA +14.64 1.381 5 & HASA2 +41.55 1.289 6 & HACA2 +31.39 1.177 7 & HASA3 +11.00 1.202 8 & HACA4 -6.15 1.273 9 & HASA5 -5.16 1.189 10 & HACA6 -5.34 1.187 11 & HACA8 +3.18 1.224 12 & HECA +9.09 2.424 13 & HESA2 +16.18 0.836 14 & HESE2 -40.98 3.376 15 & HECA2 +7.30 0.820 16 & HESA3 +1.90 0.804 17 & HECA3 -10.19 0.845 18 NPAE +129.11 11.193 19 CA -152.68 15.266 20 & HSCE8 +5.68 1.063 21 AN -5.42 2.286 22 AW +9.29 0.783 23 TF -101.37 2.800 Sky RMS = 22.67 Popn SD = 22.83 The usual geometrical model (zero points, nonperps, tilt) is the set of terms IA IE NPAE CA AN AW, and TF is Hooke's-law flexure. The rest are harmonic terms that TPOINT thought were statistically significant and which presumably are trying to map out various irregularities in bearings etc. TPOINT decided that 73 of the 1672 stars were not consistent with the model it found. They are marked in red on the first plot, fit1.jpg (attached). This is TPOINT's "nine favourite plots for an altaz" graph, and displays the pointing residuals in various ways. For example, the top left plot is left-right error versus azimuth, and the top middle is elevation error against elevation. With the outliers removed, the details become clearer - see fit2.jpg. The jagged patterns are I think what you saw in your own analyses. I got a slight improvement by manually adding a 17th-harmonic in azimuth affecting the az/el nonperp: coeff value sigma 1 IA -53.36 11.275 2 IE +96.66 3.170 3 & HASA -11.11 2.458 4 & HACA +13.87 1.358 5 & HASA2 +41.54 1.266 6 & HACA2 +31.66 1.155 7 & HASA3 +10.92 1.182 8 & HACA4 -7.03 1.254 9 & HASA5 -4.24 1.173 10 & HACA6 -5.58 1.168 11 & HACA8 +3.10 1.200 12 & HECA +9.61 2.380 13 & HESA2 +16.19 0.820 14 & HESE2 -41.02 3.310 15 & HECA2 +7.29 0.804 16 & HESA3 +1.90 0.788 17 & HECA3 -10.17 0.828 18 NPAE +132.25 10.984 19 CA -155.65 14.972 20 & HSCE8 +5.88 1.042 21 AN -5.95 2.245 22 AW +9.43 0.768 23 TF -101.29 2.745 24 HVSA14 -5.91 1.130 25 HVCA14 -6.77 1.119 Sky RMS = 22.22 Popn SD = 22.40 The revised residuals are shown in fit3.jpg. I'm sure further improvements are possible. It's instructive to plot the total pointing correction, unpolluted by observation noise. The final attachment, fit4.jpg, shows this, after the zero points have been arbitrarily fitted in order to improve the presentation. Subject: RE: 32m pointing From: "Patrick Wallace" Date: Mo, February 15, 2010 15:20 Dear Kaz, (...) By trial and error, I have found that multiplying your azOff figures by sin(El) seems to give a dAz value that is much more plausible. If I empirically introduce this sin(El) scaling, and if I ration myself to 13 coefficients, I get the following TPOINT model, with only 16 observations rejected: coeff value sigma 1 IA -141.40 8.729 2 IE +226.19 11.419 3 & HASA2 +24.58 1.190 4 & HACA2 +17.54 1.132 5 & HESE -122.07 8.415 6 & HECA +11.50 1.408 7 & HESA2 +16.30 0.820 8 & HECA3 -10.09 0.839 9 NPAE -134.80 8.496 10 CA +126.01 11.482 11 AN -7.63 1.157 12 AW +6.09 0.673 13 TF +18.42 8.740 Sky RMS = 23.00 Popn SD = 23.09 > (the covariance matrix tells me there are very, very strong > correlations). Here are the correlations using the above model. Most of the trouble is always the set of terms affecting azimuth as a function of elevation: the Az/El nonperp (NPAE) and boresight/El nonperp (CA) are highly correlated with each other and with the Az index error (IA). IE -0.0052 HASA2 -0.0300 +0.0033 HACA2 +0.1614 -0.0003 -0.0220 HESE +0.0041 -0.9858 -0.0027 +0.0002 HECA +0.0887 +0.0051 -0.0642 +0.0083 -0.0172 HESA2 -0.0040 +0.0357 +0.0029 -0.0003 -0.0418 -0.0410 HECA3 -0.0037 +0.1696 +0.0023 -0.0003 -0.1568 -0.0571 +0.0336 NPAE +0.9496 -0.0043 -0.0316 +0.2079 +0.0035 +0.0535 -0.0029 -0.0028 CA -0.9863 +0.0049 +0.0273 -0.1905 -0.0039 -0.0723 +0.0034 +0.0033 -0.9859 AN -0.1049 +0.0053 +0.0763 -0.0099 -0.0043 -0.8243 +0.0038 +0.0034 -0.0629 +0.0855 AW -0.0616 +0.0854 +0.0385 -0.0051 -0.0688 -0.0887 +0.0664 +0.0589 -0.0444 +0.0528 +0.0583 TF -0.0073 +0.9864 +0.0040 -0.0006 -0.9495 -0.0116 +0.0382 +0.1814 -0.0061 +0.0068 +0.0064 +0.1020 IA IE HASA2 HACA2 HESE HECA HESA2 HECA3 NPAE CA AN AW > If you did not correct the measurements for refraction, it got > absorbed by your model. My data file contains two sets of Az,El. The first is the properly computed observed direction, which includes refraction (albeit for average conditions). The second is my prediction of your TCS's imperfect results, plus the offsets, i.e. the demanded coordinates that would have centred on the source. The model should therefore not contain a refraction component, and indeed there is no TX term (ZD correction proportional to tan ZD). Patrick Wallace

Comparison of residuals from 25-parameter fit by Patrick (top; taken from fit3.jpg) and residuals from fitting of 13-parameter Model4c (bottom). Left-right residuals (dS = -dAz) are in left panels and elevation residuals are in right panels (dE = -dZD), all scaled in arcseconds.

Subject: RE: 32m pointing From: "Kazimierz Borkowski" Date: Fr, February 19, 2010 15:05 Dear Patrick and Others, (...) Ever since you, Patrick, suggested that our AzOff measurements might be somehow scaled (for they do not show significant increase in the scatter towards the zenith), the idea kept nagging me. After completing other urgent works I set to reanalyse the data and my fitting of the pointing model. First of all I must assure you that the azimuth offsets are NOT scaled in any way - they represent offsets just as they are measured by the azimuth counter. This assurance comes from Roman who knows best. Why then they do not exhibit this 1/cosEl pattern? I am inclined to believe it may be due to combination of 1. large nonrandom errors that are independent of El, and 2. natural properties of such measurements. In view of this, I would like to hear from you whether in your practice you have whenever seen such pattern in measurements or residuals in real data from other telescopes. I mean the pattern outlined by the red points in the appended picture (which shows the azimuth residuals from our most recent pointing Model4c). I also tried to compare your fit with what I am obtaining with my fitting program, especially with respect to the final errors as represented by rms. There are number of things that must be taken into account before any reasonable comparison. I gave you the number 17.8" that after scaling by sqrt(2) becomes 25", which is slightly worse than your 23". This number (17.8) is however one I obtained directly from the LSQ routine along with other variances/sigmas. However, the data are supplied to the routine along with individual weights for each measurement (all equal to 1 for Elev and 1/cosEl for Az offsets). Accordingly the sigma is a 'weighted sigma'. Now I somewhat modified my programs so as to get also the vector rms with and without scalings and weightings. It was interesting to see how various approaches differ in terms of final results. Here is a table summarizing what I obtained. The first line is from old results (Model4c', from larger set of data, not recalculated now) only for reference. (all numbers in arcseconds) Sigma VRMSc RMSc(Az) RMS(El) RMS(Az) RMS VRMS Model4c' 21.2 15.8 Model4c 17.82 27.10 15.54 11.21 24.17 26.64 37.67 Equal weights 24.24 27.66 22.95 12.12 22.95 25.95 36.70 Err*cos(El) 45.96 28.85 15.47 13.31 22.82 26.41 36.35 AzOff/cos(El) 25.52 38.49 24.80 11.22 55.16 56.29 79.60 Scaling AzOff*Sin(El) (Patrick's idea) Az weighted 15.90 21.92 10.79 11.13 19.89 22.80 32.24 Az weights=1 20.91 22.70 10.72 11.95 18.11 21.70 30.69 Patrick's 23.00 The 'Sigma' column is what I obtain from the fitting routine (weighted 3310 measurements), VRMSc and VRMS are rms according to your 'vector' approach (as if there were 1655 'sky offsets', direction neglected), the first one is with Az residuals scaled by cos(El) and the other (VRMS) without scaling. Remaining colums contain rms calculated the usual way (no vector treatment, no cosine scaling except for RMSc(Az)). The rows correspond to: Model4c - exact reproduction of the old analysis, Equal weights - as above but all weights equal to 1, Err*cos(El) - Az data weighted by cos(El), AzOff/cos(El) - Az data scaled by 1/cos(El) Az weighted - Az data scaled by sin(El) and weighted cos(El) Az weights=1 - as above but weighted 1. The last two cases could probably be compared to your fit that had rms=23". As is seen from the table, your and mine fits in this case have almost the same 'vector' rms. And it is much smaller than in Model4c or similar one without weighting (where it is 27 to 28"), which evidently is the result of scaling by sine(elevation). Of course, this scaling (by sinEl) should not be used in practice but it is all right for comparison purposes. Considering the lack of apparent cosine pattern makes me think that the weighting of Az offsets I have used in producing the Model4c is unjustified. Without it we would obtain somewhat different lookup table but in terms of rms really not much different from the one we have presently (as seen in the second and third line, the last two colums, of the above table). Therefore, I would be happy if you, Patrick or any one of you, had a comment especially in this respect.

Expected error pattern (red dots) in postfit residuals of azimuth offsets (black dots)

Examples of azimuth errors (dA) versus elevation angles (E) for four other radio telescopes; here 1/cos(E) pattern can be noted as larger scatter near 90 deg of elevation (these figures were provided by Patrick in response to the above mail)