Questions/Requests in preparation for A1946 (starting 19 August) ________________________________________________________________ 1) Noise diode calibration: We will need to experiment with calibration schemes. Ideally, we'd fire a cal for one second every minute or so, during data taking, so that data sensitivity will not be affected by increased noise contributed by the cal itself. Firing the cal should not require interrupting normal data taking. A 50/50 duty cycle winking cal is not so desirable. Q: Is the "on-the-fly" calibration firing scheme we propose (and recommended with a memo last January) implemented? Q: Can we access this in the off-line version of CIMA before the run? Q: What is the "warm up" time for the noise diodes? Q: What other calibration options have been proposed and/or implemented? 2) Drift mode observing overhead We will take most of the data in the following mode: set on a declination with the telescope near transit (AZ in NS position), rotate feed array to optimal angle for drift mode (feeds sweeping equally spaced strips in Dec) and start taking data. Interrupt data taking every 10 minutes, to start a new integration immediately in the same (AZ,ZA,feed rotation angle) configuration. The dead time between stop and start should be minimal (preferably one second or less). The same configuration will be kept for up to several hours, producing a series of constant declination strip segments. We request that the dead time between segments be absolutely minimal. Note: In the past, scheduling a drift scan required entering the coordinates of the center of the drift; the telescope would then slew to that center postion, then return to the starting point. That won't work for us; we require (as recommended in a memo last January) that the starting position of the drift scan be entered, and the telescope slew directly to it. For most declinations, we will point close to transit, but declinations close to zenith will require the AZ in the EW direction. Hence, this mode requires that the telescope point at an AZ (either N-S, or E-W) and ZA at the proper LST time to acquire the desired (RA, Dec) at the start of the drift. Q: Is such a "point and drift" mode now implemented? Q: Is there software that can assist in the scheduling/setup of this mode? Q: Are there any sample datasets obtained in this mode available? 3) AZ,ZA, Feed Rotation Angle Mapping Our limited azimuth drift scanning technique is designed to acquire data in drift mode that give feed tracks that are equidistant in declination. Given (AZ, ZA) or given (start LST, Declination), we need to know therefore the optimal feed rotation angle for at least AZ =N-S and AZ=E-W. At a minimum, for our August run, we need to know the optimal scheme for transit observations at Decl ~ +27 degrees Q: According to the available documentation, the optimal rotation angle for transit observations appears to be 22 degrees from some nominal feed rotation. Has that value been verified observationally? Q: Have calibration datasets been acquired that give the beam parameters with the rotation angle at optimal for transit drifts? Q: How is the rotation angle changed (under computer control or manually)? Q: Is dynamic control of the rotation angle possible during data taking? Q: Is software available to conduct quick tests of rotation angle? 4) Data Headers The early WAPP data samples made available were incomplete and contained limited information regarding offset beams. Earlier datasets also had difficulties with the timing of recorded positions. Of particular importance to us, we request that data headers will contain coordinate information *separately* for each ALFA beam, rather than only for the central pixel, and that these be updated accurately during a drift. We have previously provided comments and entirely understand that this is a transitory phase. However, in order to get our reduction processes converted from single to multiple pixel, it is important that we have access to the header structure as early as possible. Q: What is the current status of the WAPP spectral line data structure? Q: What changes are planned for the period AFTER Aug 19th? 5) Observing Preparation Tools Preparation of observations will be significantly more complex with ALFA than with a single pixel feed. Q: Are there general purpose tools that might assist observers in planning and scheduling ALFA for optimal efficiency? 6) On-Line Monitoring and Logging Software Data monitoring and bookkeeping software are of critical importance to maximize quality control and observing efficiency. While we intend to convert data to IDL formats early on, real-time monitoring tools will be necessary at the telescope. Q: What monitoring software and on what platform will NAIC make available for ALFA data? Q: What data logging software will be used and what are its capabilities? Q: How can the observer specify that more/less information be logged for his/her own use? Q: How is access to this information controlled? 7) Computer Hardware Needs In the course of A1946, spectral line data will be taken at the rate of more than 1 Gb/hr. Several hours of observing plus data processing and experimentation on various tests by a 2--to--4 person team on site will easily bring data production to near 50 Gb/day. We will need access to significant amounts of disk space and to fast workstations (old Solaris Sparcs won't do). Q: We request that NAIC provide adequate computer hardware for our use on site during the period of our observing run. Q: Can we transfer data back to our own institutions by sftp/scp? If not, what options are available? 8) Documentation It is highly desirable that the documentation illustrating the results of the commissioning tests carried out since early April be made available well in advance of our precursor run. Again, we understand the on-going nature of the commissioning task, but any information would be most appreciated. Q: Is there a draft ALFA user's manual? Q: Are there documents that summarize and update the various commissioning tests that have been performed?