Calculating New Pointing Model Constants
Bill Peters 20 Dec 96
The results of all POINTING measurements at the HHT are stored in
the directory, TEL$POINTING. (Additionally, a copy of these measurements is
also placed in the observer's FDATA:[OBS.initials] directory.) The data is
placed in files named POINTING.DAT_ddmmmyyyy, where ddmmmyyyy is MST date that
the POINTFIT command was executed. The file is appended by the Chef POINTFIT
command. The fit is written whether the ONDIS Chef has executed the command
automatically or it is done with an off line Chef. This is especially useful
if one wishes to manually include another continuum channel POINTING than that
reduced by ONDIS or if one wants to run POINTFIT on only certain subscans of a
POINTING when one or more of them are defective. (But note that if one manually
does a POINTFIT, that fit may be duplicated in the file.)
The fit information in the file is verbose and bad fits are documented
along with the good. A program called GOOD_POINT can be used to condense the
data and discard bad fits. The output file is in the proper format to be read
by the pointing model fit program, PMODEL (aka PIPSMT). GOOD_POINT can read
the original file or one which is a concatenation of several POINTING.DAT...
files. One can even edit the file, so long as one doesn't change the columns
where the data is found or add or delete lines within a fit. (One might edit a
file, for example, in order to include valid fits to a negative signal by
changing the sign of the peak to be positive.) GOOD_POINT only includes fits
with signal to noise ratios larger than a specified amount in both azimuth and
elevation, and whose peaks in azimuth and elevation agree within the specified
tolerance. Signal to noise is the peak of the gaussian fit divided by the rms
of the fit's residuals. The elevation and azimuth peaks are judged to agree if
the ratio of the maximum peak to the minimum peak in the two directions is less
than the specified value.
The following is an example of a fit in the POINTING.DAT... file.
****************************** 9-JAN-96 01:51:03 ******************************
2 Az pos.= -1.8 width= 31.6 max= 159.6 rms= 23.1 err= 1.4
1 El pos.= -7.3 width= 36.0 max= 193.1 rms= 22.8 err= 1.2
Channel: 2 RxSMT Signal freq. = 350.000000 Image freq. = 350.000000
Scan Source Az El col* nule nula daz del
8533 1226+0233C 108.05 29.00 10.40 -27.00 0.00 -1.78 -7.25
pamb tamb humi. refr. rcor. incl1 incl2
750.00 5.00 30.00 45.74 82.50 5.431E+05 5.431E+05
8533 108.05 29.00 8.62 -34.25 1.39 1.24 82.50 -10458 8.8356361
The time stamp, 9-JAN-96 01:51:03, is the MST date and time of the POINTFIT
command. The next two lines give the results of the gaussian fits: The
center position, the FWHM, the peak, the RMS residuals, and the formal error in
the center position. Next is given the continuum channel number fit, the
receiver name, and the rest frequencies. The next lines give the antenna
position and pointing offsets in use during the observation and repeat the
pointing corrections determined by the gaussian fit. This is followed by
weather data used to compute the refraction constant ("refr."), the refraction
correction at this elevation ("rcor."), and the inclinometer readings (not
implemented). The last line repeats the antenna position, shows the new Col*
and NulE, their formal errors, "rcor" again, and the CLASS day number (-10458)
and the Universal Time (8.8356361 hours) of the observation.
And this is the output of GOOD_POINT for this fit:
8533 1226+0233C 108.05 29.00 8.62 -34.25 7. 8. 350.000 2 9-JAN-1996 8.84
These are the scan number, object name, azimuth, elevation, corrected Col* &
NulE, the S/N's for azimuth and elevation, the frequency, the continuum
channel number and the observation date & UT. (In the latest version of
GOOD_POINT, the receiver name, weather station data, refraction constant, and
refraction correction follow the UT hour.)
The first line in the file written by GOOD_POINT is just the title specified
along with the S/N threshold and ratio of peaks allowed. It can be edited at
will. If GOOD_POINT was able to locate the raw data for the first observation,
it will have written next a line like
Model(8110) 348.7 55.5 -17.2 -3.1 12.9 -0.8 -350.3 16.1 0.0 0.0
These are the pointing model constants in effect for the first observation
(#8110 in this example). This will be followed by the POINTING measurements
extracted from the POINTING.DAT... file, one line per observation, such as in
the example given above for scan number 8533.
After running GOOD_POINT, one should examine the output file to check
for missing, spurious, or duplicate observations. (A change in the pointing
model during a day's POINTING.DAT... file will not be noticed. One can either
edit in the Model( ) line GOOD_POINT wrote when reading the next day's data, or
have GOOD_POINT read a file which begins with the first observation after the
pointing model change.) One can then run the pointing fit program: Type
@PMODEL .
The results of the program will be put in a file named .FIT, where
is unless that name is POINTING. If so, the
will be instead. (This file is 132 columns, so it
should only be printed with a form such as LJET132.)
PMODEL will first ask for which pointing constants to fit. One is
given the choice of "Standard", "Nasmyth", "Tertiary & Nasmyth", or "Prompt".
Choose Standard if the observations are well enough distributed in the sky to
warrant a fit to all the standard model terms. (All terms except OHor, OVer,
and Refr. As explained in the description of the pointing model, only four of
NulA, Perp, EFlx, ZFlx, OHor, and OVer can be determined from pointing
observations.)
Choose Nasmyth if there is less than full sky coverage and one is
fitting pointing data from a receiver at the same Nasmyth focus that was used
when the current Standard pointing model constants were fit. In this case, one
expects that all the model constants will be the same except for the Nasmyth
focus offsets, OHor and OVer. These will be the only pointing constants fit.
One should choose Tertiary if the latter applies but the receiver is located at
the opposite Nasmyth focus. In this case, the program solves for Col* and NulE
as well as the OHor and OVer constants.
If Prompt is chosen, then one is asked to specify which constants to
fit and which constants to hold constant/zero. PMODEL can really only solve
for *changes* in the pointing constants. So specifying that a constant is zero
means that it won't be changed. If one specifies a non-zero value for a
constant, then the change in that constant is set to the value specified. One
would only specify a non-zero value if one somehow knew what the value of that
constant should be. PMODEL can also solve for (the change in) the refraction
constant. Prompt is the only way to ask the program to solve for this
constant. (When solving for refraction, one is also given the option to remove
the refraction correction from the original data before doing the fit.)
PMODEL next asks whether one wants it to generate plots. (These are
"printer" plots included in the normal output file.) It can plot the input
data before the fit, the sky distribution of the data, and the residuals after
the fit. Ordinarily, one chooses no plots or only the sky distribution. The
plots of the data/residuals are four fold: Elevation error/residual vs
Azimuth, Elevation error/residual vs Elevation, Azimuth error/residual vs
Azimuth, and Azimuth error/residual vs Elevation. One can perhaps see from the
plots whether some data points are spurious, or whether systematic errors
remain after the model is fit (i.e. some other pointing constants should have
been fit). But usually, one learns little from these plots.
Finally, PMODEL asks about the print frequency in the output. It is a
leftover from a telescope with so many pointing observations that one didn't
want to see them all. Unfortunately, that's not the case at the HHT, so choose
1, i.e. all observations printed.
The .FIT file first prints out the input data, calculates the mean
Daz (Azimuth pointing error; Col*) and Del (Elevation pointing error; NulE),
and the standard deviation about this mean. Next comes the data plots and sky
distribution plot. Next are the standard deviations after the fits and the
*changes* to the pointing constants derived. Underneath the changes, the formal
error of each constant is printed. (0.0 usually means that no fit was made to
that constant.) Next the pointing measurements and their residuals are
printed. ** flags those measurements whose azimuth and/or elevation residual
is greater than twice the standard deviation for that axis. (Very large
residuals probably indicate a spurious measurement which should be discarded.)
Finally, (if there was a Model specified in the input data), the new values of
the pointing constants are printed. (These are simply the Model constants plus
the Changes.) A typical *good* fit at the HHT results in an rms of 2-3 arcsec
in both axes.
If one is satisfied with the fit, one can then adopt the pointing
model by editing the model constants into the file
KDATA:[SMT.ASTRO]POINTCON.DAT
(along with a comment in the first line describing the data fit). This file
contains one line per constant and has more constants than those calculated by
PMODEL. But each line has a comment specifying which constant it contains.
PMODEL's output file uses the same names, but may also print a line underneath
with a + or - and the name of another constant. This is merely to remind one
about how some of the constants couple to one another. The upper name is the
one which should be used in the POINTCON.DAT file. For this part of the file,
one should use the values from the "New pointing constants" line in the PMODEL
output. When one adopts a new pointing model for a given bolometer, one must
be sure to zero out the receiver pointing offsets (see below) for that receiver/
bolometer.
Each receiver has different pointing offsets due to misalignment of their
physical location relative to the elevation axis and possibly to misalignment
of the tertiary when flipped between the left and the right Nasmyth foci. So
following the pointing constants, are the extra offsets to adjust the pointing
model for a particular receiver. There are two lines for each receiver. The
first for a comment (usually stating the date of the observations), and the
second contains the standard name for the receiver followed by four numbers.
The name must start in column 1, but the numbers may be in any column and
should be separated by blanks. The four numbers are offsets to Col*, NulE,
OHor, and OVer. These are added to the values for these constants in the
beginning of the file to give the actual pointing model constants used for that
receiver. When one modifies these offsets, be certain to use the values from
the "CHANGES to model parameters" line in the PMODEL output rather than the
"New Pointing Constants" line which was used for the model constants in the
beginning of the file. And if these offsets in the original file were non-
zero, these CHANGES should be *added* to the old offsets in order to get
the new ones.
One can combine the data from several GOOD_POINT files to be read by
PMODEL. One should use an editor to combine the data. There should be only
one title line (edited to describe the combined data), but there may be
more than one Model( ) line. This is especially important if different model
constants were used for some observations than for others. When PMODEL
encounters a second Model( ) line, it assumes that these model constants were
used for all the subsequent observations (until another Model( ) line is read).
It then corrects the pointing measurements for the difference between the
first Model( ) constants and the current Model( ) contants.
If PMODEL encounters a line like Model( ) but named Adjust( ), it will
correct the subsequent data by subtracting the pointing model specified until
another Model( ) line is found. The effect of Adjust( ) is the same as that of
a Model( ) line whose constants are equal to that of the first Model( ) minus
those of the Adjust( ) line(s). It is intended to be used to combine the data
from two different receivers/bolometers whose relative Nasmyth and/or Tertiary
offsets are known. If the second receiver data was also taken with a different
pointing model in effect, the Model( ) line should be first and the Adjust( )
line second. The resulting constants printed by PMODEL will correspond to
the constants needed for the first receiver. (The order of the constants in
the Model/Adjust lines are the same as printed by PMODEL.)