THE GBT OBSERVER INTERFACE. I. POINTING THE GBT: THE ASTRONOMICAL POINTING SYSTEM (APS) RAMIFICATIONS FOR M&C AND AIPS++ This memo discusses the need for and characteristics of software to measure GBT pointing using astronomical techniques: an astronomical pointing system (APS) for the GBT. The basic requirements on the APS are to measure the parameters of the telescope beam, including its position; to determine pointing corrections; and to apply the determined corrections to future observations. We believe that these requirements are best handled with a combination of the M&C and AIPS++ software packages, and our memo is written accordingly. We acknowledge the possibility that our belief may be erroneous, in which case all of these requirements would have to be handled in M&C. In either case, the requirements on APS capability are important to achieve at the very beginning of GBT operation, and the capability should be available independently of the precise way in which it is provided. In our picture of the M&C/AIPS++ combination, each package has certain distinct responsibilities. M&C is responsible for taking the data and the basic level of data inspection, a GUI-based strip chart recorder, the minimum characteristics of which are outlined in the appendix. The requirements on AIPS++ involve higher levels of data presentation, data analysis, and feedback of parameters to the M&C system, and are outlined in sections 2.2 and 2.4. 1. WHY HAVE AN APS? Intrinsically, the GBT should have unsurpassed pointing accuracy and reliability because of its laser referencing system. Lasers are mounted on the telescope structure and determine its position with respect to fixed points on the ground with arcsecond accuracy. With this system, an attempt to refine pointing by astronomical measurements may be fruitless because the attainable accuracy might be less than the intrinsic accuracy of the laser referencing system. Nevertheless, it will certainly be necessary to measure pointing astronomically for a number of reasons: * Acceptance of the telescope from RSI will require our checking its performance by itself, independent of our add-on laser pointing and surface adjustment systems. This check must occur at the very beginning of operation. * An important component of the total pointing system (GBT memo 103) is a a traditional pointing system--a standard pointing equation. The only way to determine the coefficients in this equation is by making astronomical pointing measurements. * The laser pointing system must be checked for accuracy and reliability, particularly at the beginning of its operation. And in ongoing operation, the laser pointing system is designed to be extremely accurate and reliable to eliminate the requirement for frequent astronomical pointing calibration; however, the accuracy and reliability are attained by using intricate, complicated systems, and the entire arrangement must be periodically checked for proper operation. * Ground fog (or malfunction) may render the laser pointing system inoperable; it is often true that the atmosphere is very stable and dry during periods of ground fog, providing excellent conditions for high-frequency observations with a concomitant requirement for accurate pointing. * The position of the telescope SURFACE varies with respect to that of the telescope STRUCTURE, both inherently because of thermal and gravitational deformation and extrinsically because we intend to use actuators to move the surface with respect to the structure. (In principle, the relative position of surface and structure will be both controlled and accurately measured by the laser ranging system, but again we will need to check this system for accuracy and reliability). * The exact position of the electrical focal point of a feed is a calculated quantity and needs to be verified empirically; the best method is astronomical pointing. * When a receiver is reinstalled its position may change slightly from its previous position, and this should be checked astronomically. * Careful users never accept anyone's word that a system works properly; neither do they trust complicated systems. They will want to verify proper system operation at the beginning of and periodically throughout their observing runs. * A user may wish to incorporate small pointing corrections in future observations, especially future 'local' observations that are nearby in both time and position. This will be particularly important if one of the laser systems is malfunctioning and may also be important for VLBI observations. Many of the reasons for determining the pointing astronomically involve checking whether systems operate properly and gaining confidence in their operation. These reasons will assume particularly large importance at the beginning of the operation of the GBT. This means that it is extremely important to have a fully functioning APS right at the very beginning of operation. The alternative would be to develop the APS during the initial stages of operation and let it evolve as we gain experience. This alternative would work, but it would be poor management. 2. WHAT WE REQUIRE FROM THE APS. There are four fundamental requirements for the APS. One, it must measure the pointing and other beam parameters astronomically with an accuracy that is limited only by statistical noise and by unavoidable systematic effects. Two, it must present the results to the user. Three, the user must be able to incorporate the results in future observations. Four, it must be user-friendly. 2.1. ACCURACY AND SYSTEMATIC EFFECTS. 2.1.1. TOTAL POWER, BEAM SWITCHING, OR SPECTRAL LINE? At high frequencies, the main deterrent to accurate position measurements is the time and space variability of the earth's atmosphere. At low frequencies, the main deterrent is the presence of unrelated cosmic background radiation, both extended Galactic emission and confusing point sources. At high frequencies, the variability of the atmosphere can be dealt with using three methods. Two methods use continuum sources: one method uses rapid beam switching and the other does not, and in both cases one makes a large number of repeated measurements to statistically average the time variability. Rapid beam switching will be possible with some, but not all, of the GBT receivers. With these continuum methods, space variability of the atmosphere must be dealt with by making enough measurements on the source to remove a sloping background. The third method involves using a strong maser instead of a continuum source. This method is best because it automatically cancels both time and space variability of the atmosphere. Suitable masers include the SiO masers near 43 GHz, the H2O masers near 22 GHz, the CH3OH masers near 12 and 7 GHz, and the OH masers near 1.7, 5, and 6 GHz. If one needs to determine the pointing of a feed for which neither rapid beam switching nor the maser method is possible, then one must make a large number of repeated continuum measurements to eliminate atmospheric effects. This is the least desirable of the three methods because it is slow. However, one can avoid this method if the focal points of the various feeds have been accurately determined because the turret positioning system is extremely accurate. In this case, one determines the pointing with a suitable feed, say one that can see a maser, and then repositions the turret to place the desired feed at the focal point. Unfortunately, under present plans the turret cannot be rotated except when the telescope is pointed to the zenith, which will make this method unnecessarily cumbersome--and possibly useless, because it is possible that moving the telescope to zenith and then back to the source region may invalidate the pointing measurement because of hysterisis in the structure or time variability of the pointing. At low frequencies, the confusing effects of the Galactic emission and background point sources require making pointing measurements on a strong continuum source or a maser. The 1.7-GHz OH masers are particularly good. There are no masers at the low frequencies covered by the prime-focus receivers, but the relative locations of the prime and Gregorian foci should be known well enough that low-frequency pointing should never be a significant problem. 2.2.2. TECHNIQUE OF MEASUREMENT. Technique is important. First, we cannot assume that the beam is circular. Noncircular beams are the rule for linear polarization on axisymmetric telescopes; they should also be the rule for the GBT, which is nonaxisymmetric. Furthermore, one will sometimes be interested in measuring the pointing of an off-axis feed, which has aberrations: the beam is not circular and the peak is not at the center. The beam can be represented as elliptical, with a Gaussian cross section on the minor axis and a skewed Gaussian on the major axis. Specification of such a typical GBT beam requires 7 parameters: central position; peak gain; major and minor beamwidths; skewness of major-axis cross section; and orientation of ellipse. These parameters are best measured by providing some redundancy in the measurements. A convenient solution is to perform four 'scans' that cut through the astronomical source at relative angles of 45 degrees. If one can be confident that there is no background, as in a maser measurement, then each 'scan' can be a three- or five-point measurement; such discrete-point measurements are suitable for maser observations, which must be taken with the correlator. If there is a background, as in a continuum measurement, each 'scan' must contain at least five points, and if the background is time-variable then each 'scan' should be a continuous scan instead of discrete points. The orientation of the set of four scans should be selectable so that it can be lined up with, for example, telescope coordinates, celestial coordinates, or direction of linear polarization. 2.2. PRESENTATION OF RESULTS TO THE USER. Presentation occurs at several levels. In the most basic, the user needs to be able to assess the quality of an observation. Observations of this kind can be ruined by time variability. The easiest way to display time variability is with a strip chart recorder. We certainly do not advocate using real strip chart recorders! Rather, we advocate generating a sophisticated equivalent on a GUI. The simulation of a strip chart on a GUI should do more than simply duplicate all of the functions of an old-fashioned Esterline-Angus. Rather, it should incorporate the features that are inherent in computer displays. We outline the requirements for a GUI- emulated strip chart recorder in the appendix of this memo. At the higher levels, the techniques of presentation are variants on the general problem of data presentation. The general problem is the domain of AIPS++. Accordingly, we believe that AIPS++ is the appropriate package to deal with the higher levels, as we now outline. The second level involves viewing the data and the derivation of the beam parameters. This derivation involves nonlinear least-squares fitting to derive the Gaussian-like beam parameters. Nonlinear fits require beginning with an initial 'guess' of the final answer. It is usually not difficult to use an automatic algorithm to provide the initial guess. However, in some cases the user may wish to improve on the algorithm's guess. The user should be able to view the raw data in both GUI and numerical form, and should be able to provide an initial guess either with a mouse on the GUI or numerically. Often, the best version of the initial guess is the results derived from a previous fit, and this should be easily available for use as the initial guess. Various fitting algorithms should be employed. Examples: The user may be confident that the beam is circular, or alternatively may wish to force a fit to a circular beam; or the user may specifically wish to test for skewness. In most circumstances it makes sense to employ all methods and present all results to the user. But in some cases, for example because of inadequate signal/noise or systematic effects, it may be best to employ only a single method, and this option should be available. There are at least three reasons that a user wants to know the result. One is to determine the pointing accuracy of the telescope. Two is to determine the beam shape and efficiency. Three is to apply the derived pointing corrections to a series of future observations. The first two together constitute knowing all seven parameters of the beam. The system should present the user with these parameters defined with respect to any local coordinate system of the user's choice, such as Galactic coordinates, the equatorial plane of Jupiter, and/or local altitude/azimuth. The APS will be employed not simply by users for temporary purposes. It will also be employed at the beginning, and periodically thereafter, to determine the 'traditional pointing equation' for the GBT. For example, when the laser systems are not being employed, the GBT is like an ordinary single dish. That is, the relation between the true sky position and the encoder position is given by a predetermined, fixed pointing equation. The form of this equation for the GBT will differ in some ways from that for an ordinary telescope. AIPS++ should be able to take the pointing data obtained by the APS and perform a least-squares fit for the coefficients in an arbitrary equation; generating the most suitable 'traditional pointing equation' will probably involve experimentation with different forms of the equation. Finally, AIPS++ and the M&C system must be able feed results to each other. Feeding data from M&C to AIPS++ is simply a variant on the ordinary, in which astronomical data is fed from some telescope to AIPS++. But feeding information back from AIPS++ to M&C is not ordinary. A straightforward, easily-executable method must be provided. 2.3. APPLYING THE RESULTS TO FUTURE 'LOCAL' OBSERVATIONS. If a user wants to apply the results to future 'local' observations, i.e. observations localized in both time and a limited region of angle, then it is likely that the user has already been applying results of previous pointing checks to observations. It should be possible for a user to easily compare the current and previous results. The user should be able to apply the results to future local observations with a simple command that so informs the system. This also requires feedback of the pointing parameters from AIPS++ to M&C. This feedback must be at the option of the user, who can judge the quality of the derived corrections. Furthermore, the user may wish to average the derived corrections with those obtained previously, either on the same source or other sources. 2.4. THE APS MUST BE USER FRIENDLY. In line with GBT Memo 81, the APS must have both a GUI and a command line interface. This applies both to invoking the APS and to presentation of the results. The APS should have a built-in source catalog. Each source should be specified for quality (e.g. flux density, absence of confusing background) as a function of frequency. Many sources are time-variable: continuum sources vary in flux density, and masers also vary in frequency. The catalog should be kept current, and this is best done routinely by use of a scheme such as the following. Whenever the APS is invoked, no fewer than three sources are observed; the results from the three sources are compared; if there is a discrepancy, the sources are flagged for inspection by a staff member, and the catalog appropriately updated. The APS should be able to, first, select a set of optimum calibration sources for any particular receiver on the basis of user- specified criteria. For example, the user may need accurate pointing for observations during the next hour near the eastern horizon. The APS should then either go ahead and observe automatically from its selected list or provide the user with the opportunity to select one or more sources from the list. Alternatively, the APS should allow the user to provide an independent list. In presenting the results, the beam shape and orientation with respect to the user's preferred coordinate system should be presented in various graphical formats, such as contour and/or grey- scale images. Further, the seven beam parameters should be stored with previous measurements so that a set of measurements can be presented in convenient tabular form and a user can examine the history of the measurements for the purpose of seeing changes with time or assessing the true observational accuracy. And it should be easy for the user to generate appropriate graphical displays of this tabular information, including not only plotting the various parameters versus time or angles such as azimuth, but also versus each other. If the user wishes to apply the previous pointing data, or the average of a set of data, to future observations as pointing corrections, the user should be able to specify exactly which data to include on the table, for example with a mouse, and instruct the system to use the data with a simple command such as 'apply_corrections'. APPENDIX A GUI-BASED STRIP CHART RECORDER The basic function of a strip chart recorder is to provide a graphical presentation of time dependence. Real strip chart recorders have many positive virtues: one can change the scale and zero level easily, with knobs; one can annotate the chart before, during, and after the fact; one can plot, simultaneously, more than one quantity; one can make a quick estimate of position or intensity from the analog chart; the output lasts forever. A GUI simulated chart recorder must have all these virtues and more. In particular, one should be able to annotate the 'chart' at any position by moving a mouse; one should be able to obtain numerical values of both the time and the measured quantity at any point specified by the position of a mouse, whether or not that point happens to be a real data point; one should be able to display the numerical values of time and data for any mouse-specified data point; one should be able to measure intervals between a current mouse-specified point and a previous one by clicking appropriately on the mouse. One should be able to 'unroll the paper to any position' and hold it steady for examination/inspection/annotation, even though data are currently accumulating on the 'chart paper'. One should be able to make a hard copy--a REAL chart! Real strip chart recorders have some disadvantages, apart from paper pollution. The most serious is that once a user selects the zero point, intensity scale, and chart speed, the data cannot be replotted. Such after-the-fact rescaling is a trivial feature for a GUI, and a user should be able to accomplish rescaling by easy mouse- clicking rather than by typing.