Subsections


2. The Computers


2.1 Summit Computer System: Overview

The CSO summit computer system is based on a loosely coupled network of workstations and micro computers. The philosophy behind this is now quite common amongst observatories. The basic aim is to minimize inter-processor communications, particularly any which need to be high speed, as intra-processor communications (between different tasks for example) are much easier to synchronize and manage than inter-processor communications. The result is that tasks are allocated to individual computers based on a combination of their real-time, electro-mechanical and functional relationships to each other. This produces an extremely simple system, with clear cut task allocation between the different computers.

In functional groups, there are three Digital workstations running OpenVMS, two SUN Ultra workstations running Solaris, two PowerPCs running LynxOS, a Macintosh computer named sharc running an instrument of its namesake, and a host of Linux and Window PCs.

The VMS machines consist of a VAXstation, called poliahu, two identical DEC Alpha workstations, alpha1 and alpha2. The three machines run in a cluster which enables sharing of their CPU as well as disk resources. They also share user account information and the user directories which are on a pair of SCSI disks constantly mirroring each other, providing a higher level of protection for disk failures. The three machines form a stable cluster in that we can afford to have any one of them hung without impacting on the operation of the remaining two, ensuring the least amount of interruption to observations due to computer failures.

The primary observer interface for antenna and instrument controls, the UIP (User Interface Program) software package, has moved from poliahu to the faster and more capable alpha1 (and soon alpha2 too). The UIP controls almost all aspects of the observing chain, from antenna and backend spectrometer control, to setting up command files (or scripts) for extended observing. It interprets commands from the observer, and passes them on as suitable to the various microcomputers. This includes such things as finding sources in catalogs, and requesting the Antenna computer to drive the antenna to position and track the source, setup the backend (AOS or SHARC) system with correct integration time and switching format, and to actually perform the integrations, and transfer data (be it spectra or continuum) from backend to user directory on alpha1 for further processing, as well as prepare the data file to be uploaded by one of the Solaris machines for archiving into the Sybase database at the end of the day. The two alphas are truly sharing their CPU resources: any task that runs on alpha1 can be run on alpha2, including a java-enabled Netscape and a whole host of Unix-like utilities (such as xv, zip, tar, etc.). The venerable poliahu, aside from providing a critical quorum for the cluster, is tied to the receiver computer at its boot time. It also runs a small number of ``legacy'' user applications for data processing that have yet to be ported to the SUN workstations or the alphas. Data reduction programs, such as CLASS, CAMERA, BADRS, run on poliahu, so is CLASS on alpha1, though newer versions of these programs are no longer ported to VMS machines.

The SUN workstations include two SUN Ultra 1 workstations (hapuna and kilauea). An NIS is running between the two, so a user account on one is as good as on any other. Needless to say the user disk is shared, so are the mails and most of the user utilities. These machines are to provide some homely comfort to observers from a SUN Solaris world. They also do a fair amount of heavy-lifting for the observatory too: kilauea runs Sybase servers for data achieving and Apache web servers to answer queries on CSO database searches (with links from the main CSO webpage). It also doubles as a caching domain name server for the local domain and a secondary network time server. Hapuna serves user disk and application disk to other SUN workstation. It also runs the anonymous ftp server (aliased to ftp.cso.caltech.edu). The machine has proved to be the most preferred console by observers in the control room. Most of the data reduction, the whole suite of GAG package (CLASS, Greg, Gildas, etc.), Camera, SAOImage, SuperMongo, to name a few, can be done on any of the SUN workstations. Observers home directories on alpha1 (where data is being acquired) are accessible at /user_vax/acct_name. As we tighten up network security for the Observatory, these machines also serve as gateways for accessing observatory computers from off-site locations via Secure Shell (ssh).

The PowerPCs perform real-time or time-critical tasks. They are VMEbus based with a PowerPC CPU module and other off-the-shelf commercial modules. One is the antenna computer, named hau. It controls the telescope axes, secondary mirror focus and beam switch, Sidecab receiver optics and local phase locks, Cassegrain instrument rotators, and status monitors. In addition, it is a NTP server for the observatory, using a local GPS and/or WWV clock as reference. The other is the backend computer, and it runs the four Accousto Optic Spectrographs (AOSes). Both are mounted on the same rack in the Receiver Lab/AOS Room. SHARC is run by a Macintosh computer in the control room. During normal operation, the various computers talk to each other primarily over ethernet. The only exceptions to this are a few bits of time-critical information (phase lock loop and source acquisition status, for example) which are bussed around the observatory on TTL lines.

The unassuming Linux box, puuoo, a mere Pentium 120 machine, carries alot of weight. It serves the Observatory's webpage (aliased to www.cso.caltech.edu), and is the default Xwindow AOS display for the backend computer. It also doubles as the print server for the summit computers. It is constantly busy number crunching in the background to serve up the tau plots popular in the summit community. Puuoo will soon be upgraded to a relative ``modern'' dual-processor Linux PC rack-mounted along with the CISCO router and switch on the corridor outside of the computer room.

Pika, the Window box currently sitting next to puuoo, is provided for your web surfing pleasure (when things are slow...). Indeed, web surfing is now an integral part of observing at CSO, as you check on the weather , look at the tau plots , or help yourself diagnosing problems with the trouble shooting guide . It also manages AutoCAD drawings for the observatory engineering crews. One other useful feature of pika is that via a XReflection link you can turn the console into that of a host of other machines (hapuna, kilauea, alpha1, and poliahu) you are logging in as if you were on that machine's console. You can even set up keyboard to stimulate that of the target machine.

Another Window box, ahi, in the computer room, serves the similar purposes.

We also maintain two PCs in our Hale Pohaku office. One is a late model Linux box called ono. The other one is a window95 box called puka for those who wish to have brought along Window based laptop. Ono is loaded with a full array of data reduction packages, if that is how you choose to spend your time there. And of course, there is Netscape on both machines.

You are welcome to bring along your laptop when you come to observe at CSO. Instructions on getting on-line are posted on the chalk board in our Hale Pohaku office as well as in the control room on the Summit. This ``on-line service'' can be arranged too at our Hilo office if you plan to spend some time there.


2.2 Message Passing Between Computers

Many different pieces of software in the alpha1 will want to talk to one of the microcomputers, more or less at the same time. This creates a potential problem because the responses from the microcomputers must be sent back to the appropriate process. Also certain operations, such as sending a spectrum from the backend computer to alpha1 must execute uninterrupted until completion. The way access to the antenna computer is synchronized is by giving a special process exclusive control over the access to its ethernet port, and having it route the messages to and from other processes. This process is called ANT_MCP.

Things are a bit more complicated for the backend computer. The observer tells the backend computer which AOSes are to be active by issuing the AOS command with the proper qualifiers. Each active AOS has its own process running in the backend computer. The AOS process is started by a ``Client'' process on alpha1. The name of the Client process will be AOS #n Client, where n is the number of the AOS. This client process controls access to the TCP/IP link to the backend computer over which commands are sent. Each active AOS also creates four additional TCP/IP links between the backend computer and alpha1. These links are used to report error conditions, to set VMS event flags, to transfer spectra and to send periodic messages verifying that the system is okay. There is a more detailed description of these processes in section 2.7. If you get a message such as
``Timeout of 50 MHz AOS EKG channel - the backend computer may have died."
that means that the process controlling AOS 2 in the backend computer is no longer exchanging ``I'm alive'' messages with alpha1. It often means that the backend computer has crashed.

The communication protocol between alpha1 and SHARC's Macintosh is nearly the same as for alpha1 and the backend computer. The UIP's SHARC command starts a client process on alpha1, which then sets up a TCP/IP link to the Mac. On the Mac end, Labview software is started by this first TCP/IP link, and the Labview software then creates several more TCP/IP links to alpha1, which are serviced by server processes on alpha1.

It is possible to write code for alpha1 that allows you to communicate directly with the microcomputers, without invoking the UIP at all. This is what is done by the holography software (the authors of which hated the UIP). Doing this is fairly easy. First you must obtain an exclusive VMS lock on the name of the microcomputer process you wish to communicate with. For example, to send a message to the antenna computer, you must get an exclusive lock on the resource called ANT. Then you write your message to a mailbox - in the case of the antenna computer this mailbox is called TO_ANT. Next you should read all messages that return over the corresponding "FROM" mailbox - FROM_ANT in the case of the antenna computer. The last message will be a special End-Of-File message. Finally you must release the exclusive VMS lock so that other programs may communicate with the micro.


2.3 Antenna Computer Display

Here is what you should see (approximately) on the antenna computer display screen. The antenna computer can display several ``pages'' of information on this screen. This is Page 1, the default display. Observers will almost never need to look at any other page. The UIP's PAGE command allows you to select the active page.
Date
This is the date (well duh!).
DOY - Day of Year
Day number of the current UT date.
MJD - Modified Julian Date
This is the current Julian date minus 2400000.5 in days.
UTC - Coordinated Universal Time
This is the current Coordinated Universal Time. If this time is not updating, the antenna computer is definitely not running.
DAT
This is the difference between TAI (International Atomic Time) and UTC in seconds.
DUT
This is the difference between UT1 (Earth rotation time) and UTC in seconds.
LST - Local Sidereal Time
This is the current hour angle of the vernal equinox. You'd better know stuff like this!
AAZ - Actual Azimuth
This is the current azimuth, in decimal degrees, of the telescope.
AZA - Actual Zenith Angle
This is the current zenith angle, in decimal degrees, of the telescope. We should really be using elevation...
RAZ - Requested Azimuth
This is the azimuth, in decimal degrees, that the telescope should have. It is the position the servo system is trying to acquire.
RZA - Requested Zenith Angle
This is the zenith angle, in decimal degrees, that the telescope should have. It is the position the servo system is trying to acquire.
EAZ - Azimuth Error
This is the difference, in arc seconds, between the telescope's current azimuth, and the azimuth the telescope should have.
EZA - Zenith Angle Error
This is the difference, in arc seconds, between the telescope's current zenith angle, and the zenith angle the telescope should have.
RAO - Right Ascension Offset
This is an offset in arc seconds in Right Ascension, on the sky. It is corrected for the variation with declination of the size of an R.A. step. Although you are welcome to use this offset (you can set it with the UIP's RAO command), this offset is used by the computer in OTF mapping, and also if you specify a ``Designated Offset''. Usually it is better to use the ``Mapping'' offsets to map a source (with RAO/map command, or use the ``Field'' offset to offset entire OTF maps (with RAO/FIELD command).
DECO - Declination Offset
This is an offset in arc secondsn Declination, on the sky. Although you are welcome to use this offset (you can set it with the UIP's DECO command), this offset is used by the computer in OTF mapping, and also if you specify a ``Designated Offset''. Usually it is better to use the ``Mapping'' offsets to map a source (with DECO/map command, or use the ``Field'' offset to offset entire OTF maps (with DECO/FIELD command).
AZO - Azimuth Offset
This is an offset in arc seconds in Azimuth Angle, on the sky. It is corrected for the variation with zenith angle of the size of an azimuth step. Although you are welcome to use this offset (you can set it with the UIP's AZO command), this offset is used by the computer when CALIBRATION and CHOP_SLEWY scans are taken, so your value is apt to be overwritten. Usually it is better to use the ``Mapping'' offsets to map a source.
ZAO - Zenith Angle Offset
This is an offset in arc seconds in Zenith Angle, on the sky. You may change the value of this offset using the UIP's ZAO command.
GLO - Galactic Longitude Offset
This is an offset in arc seconds, on the sky. It is corrected for the variation with galactic latitude of the size of a galactic longitude step. You may change this offset using the UIP's GLO command.
The Galactic coordinates in the antenna computer are not very accurate. They Should not be used for mapping!
GBO - Galactic Latitude Offset
This is an offset in arc seconds, on the sky. You may change this offset using the UIP's GBO command.
The Galactic coordinates in the antenna computer are not very accurate. They Should not be used for mapping!
FAZO - Fixed Azimuth Offset
This is an offset in arc seconds, on the sky. It is corrected for the variation with zenith angle of the size of an azimuth step. The ``Fixed Offsets'' are used to correct for the receivers' small collimation errors. They should be changed only when pointing. Default values are loaded by the UIP's POINTING_FILE command. You can change them manually using the UIP's FAZO command.
FZAO - Fixed Zenith Angle Offset
This is an offset in arc seconds, on the sky. The ``Fixed Offsets'' are used to correct for the receivers' small collimation errors. They should be changed only when pointing. Default values are loaded by the UIP's POINTING_FILE command. You can change them manually using the UIP's FZAO command.
TAZO - Tracking Azimuth Offset
This is an offset in arc seconds, on the sky. It is corrected for the variation with zenith angle of the size of an azimuth step. This offset is internally generated in the antenna computer, to compensate for pointing changes caused by moving the secondary (to follow the focus curve). You can not change this offset, and it probably shouldn't even be displayed on the default page.
TZAO - Tracking Zenith Angle Offset
This is an offset in arc seconds, on the sky. This offset is internally generated in the antenna computer, to compensate for pointing changes caused by moving the secondary (to follow the focus curve). You can not change this offset, and it probably shouldn't even be displayed on the default page.
POINTING - Pointing Constants File
This is the name of the last pointing file specified with the UIP's POINTING command. When you issue the POINTING command, the computer loads in the default ``Fixed'' offsets for the specified receiver, and the secondary mirror focus offsets, if any. It also tells the computer were to log any pointing results.
The pointing files are located in the directory PNT_DIR: on the VAX and Alpha, and they all have the extension .POINTING_SETUP. The UIP command POINTING * will list all the known pointing setups.
Refrac - Refraction Correction
This is the refraction correction, in arc seconds. It is obviously applied to the zenith angle, and always moves the telescope away from the horizon. Unless the pointing setup is ``optical'', the refraction is calculated based on the radio refraction model given by Berman et al. (1975) in JPL tech report 32-1601.
Source - Source Name
This is the source name from your source catalog. It is the name you gave when you issued the UIP's OBSERVE command (truncated to eight characters for display purposes).
Epoch - Coordinate Epoch
This is the epoch of the coordinates of the current object. Currently, the antenna computer can handle both J2000 and B1950, and has a clear preference to J2000 (as shown here). But for historical reasons all the sources entered into catalog under UIP are stored in B1950 system, even you can enter the source in B1950 or J2000, or some other equatorial/Galactic systems.
RAEP - Catalog Right Ascension
This is the object's J2000 coordinate.
DECEP - Catalog Declination
This is the object's J2000 coordinate.
RA - Current Right Ascension
This is the object's position at this moment, corrected for precession, nutation, aberration etc.
DEC - Current Declination
This is the object's position at this moment, corrected for precession, nutation, aberration etc.
HA - Hour Angle
This tells you how far your source is from (when negative) or after (when positive) transit in hour:min:sec.
P Angle - Parallactic Angle
This is the angle between local zenith and the North Pole, spanned from the source. It measure the source orientation on the sky.
Tracking - Telescope Status
The current telescope status shows up here. The possible values are IDLE (not trying to move or even servo to the current position), TRACKING (trying to servo to the requested azimuth and zenith angle) and STOWED (essentially identical to IDLE).
Acq - Tracking Status
This field displays Acq if you are within the Acquire Limits of the requested position, and Not Acq otherwise. You can change the acquire limits using the UIP's ACQUIRE_LIMITS command.
Celes - Tracking Mode
This field displays the current tracking mode, which is the method by which new requested azimuth and zenith angle values are being derived. Possible values for this field are Celes, Planet and Altaz.
Stop Button Indicator
This indicates that one or more of the big red ``Stop Buttons'' is engaged. When this indicator is present, you cannot move the telescope, dome, or shutter. You should be able to locate the active Stop Button by examining the Control Panel.
If a Stop Button somewhere other than the control room is engaged, you should try to find out who pushed it and why, before disengaging it. This is particularly true during the daytime, when people might be working in dangerous places (under the dome, etc.).
It is sometimes useful to fool the antenna computer into thinking that a Stop Button has been pushed, even when it hasn't. This will disable telescope and dome motion via software. The command to do that is
UIP> TOA ALWAYS_PANIC 1SET.
To undo the above, issue the command
UIP> TOA ALWAYS_PANIC 0SET
Line - Spectral Line Name
This is the name of the spectral line being observed. It is specified when you enter the UIP's LO command. Information about spectral lines is stored in spectral line catalogs. There is a system-wide default catalog, and users may have their own line catalogs. A list of the currently open line catalogs can be obtained with the UIP command CATALOG/LINE. New spectral lines maybe added to the user's default line catalog (private_catalog.line_cat under your home directory) with the UIP's LINE command. If you would like to add a new spectral line to a catalog other than your default catalog, say diatomic.line_cat, you can use LINE/catalog=cat# where cat# is the number associated with diatomic.line_cat in the directory listing when you do CATALOG/LINE.
F rest - Rest Frequency
This is the Rest Frequency, or laboratory frequency, of the spectral line, in GHz. It is obtained from the line catalog, when you issue the UIP's LO command.
Sideband
Our heterodyne receivers all operate in the ``double sideband'' mode, which means that two sky frequencies, separated by an interval equal to twice the IF frequency, are mapped to each frequency in the IF bandpass. This sideband indicator specifies whether the line will appear in the lower or upper (higher) frequency sideband. By default, the sideband information is obtained from the line catalog, but you may override that when you issue the LO command by including either the /LOWER or /UPPER qualifier.
It is important to choose the correct sideband, because you might have an accidental overlap with another line if you choose incorrectly. On the other hand, sometimes choosing the sideband carefully will allow you to observe two lines simultaneously (for example CS(7-6) in the lower sideband, and CO(3-2) in the upper one). The LINECAT program on poliahu has a graphic mode which will display where all well-known lines will fall in the IF bandpass, for any particular setup.
Another reason you should select your sideband carefully is that noise enters the system through both sidebands. So if you are not trying to observe lines in both sidebands simultaneously, you should put the unused (``image'') sideband at the frequency where the atmospheric opacity is lowest. Often a quick look on where your program line is on the atmospheric transmission curve over Mauna Kea would suffice to decide which sideband the line should be in. On the other hand, you may want to use the DSB program, again on poliahu, to help you to do that.
MUL/IF - Harmonics and Intermediate Frequency
MUL is the harmonic number that the multiplier in the receiver's LO chain is configured to produce. In other words, the Gunn oscillator's frequency is multiplied by this number. By default, this number is obtained from the line catalog when you give the LO command, but you can override the default value by using the /MULTIPLIER qualifier on the LO command.
IF shows the IF frequency, in GHz. Normally we use an IF of 1.5 GHz, but this can be changed in the range of 1.2 - 1.8 GHz using the /IF= qualifier on the UIP's LO command.
If you change the IF frequency with the LO command, you will normally want to change the center frequency of the AOSes too (although it is not required by the software). For example, if you were using AOS #1, and you wished to observe normally with an IF of 1.4 GHz, you'd need to issue the following commands
UIP> LO/IF=1.4
UIP> AOS/AOS1=1.4
Be careful though to reset the IF to 1.5 GHz when you're done, as it would otherwise stay on and you will find out you no longer see the line you saw before fiddling with the IF.
V offset - Velocity Offset
This is an offset (in km/sec) that is applied when the antenna computer calculates the Doppler corrected frequency to send to the Phase Lock Loop. The line should appear shifted from the bandpass center by this amount in the final spectrum. This offset is entered by using the /V_OFFSET= qualifier on the UIP's LO command.
F offset - Frequency Offset
This is an offset (in GHz) that is applied when the antenna computer calculates the Doppler corrected frequency to send to the Phase Lock Loop. The line should appear shifted from the bandpass center by this amount in the final spectrum. This offset is entered by using the /F_OFFSET= qualifier on the UIP's LO command.
V LSR - Local Standard of Rest Velocity
The LSR velocity (in km/sec) is obtained from the source catalog. It cannot be overridden. If you need to change it, you must edit the source information, which can be done with the UIP's VERIFY/EDIT sourcename command. Currently we can only use LSR or simple radial velocities. We can't use heliocentric velocities, or Z, etc.
F LOCK - Lock Frequency
This is the frequency, in GHz, that the Gunn oscillator should be tuned to. The Gunn oscillator is the uppermost component of the LO chain on the receiver. Observers must tune the Gunn any time the frequency is changed appreciably. There are tuning charts for each Gunn just inside the sidecab, taped to the wall.
V radial - Radial Velocity
This velocity, displayed in km/sec, is normally calculated by the antenna computer. Normally observers don't directly change this number. However, if you wish to, you can directly specify the radial velocity to be used in the Doppler shift calculation, by using the UIP's LO/RADIAL_VELOCITY= command. If you directly specify the radial velocity, keep in mind that the antenna computer will use it directly, and not apply any corrections for the earth's rotation, etc.
PLL - Phase Lock Loop
It shows the phase lock status, which can be simply LOCKED, or GUNN UNLOCKED, or YIG UNLOCKED, depending on the status of the Gunn Oscillator's Phase Lock Loop. If the antenna computer cannot talk to the Phase Lock Loop system (because it is dead, or unplugged) a blinking error message will appear here.
X POS - Secondary Mirror X Position
This is the secondary Mirror's X position in millimeters. If the telescope is tipped to the horizon, X is the direction parallel to the horizon and perpendicular to the telescope's optical axis. Positive motion is towards the compressor platform, and away from the sidecab. Normally, this value never changes.
Y POS - Secondary Mirror Y Position
This is the secondary Mirror's Y position in millimeters. If the telescope is tipped to the horizon, Y is the direction is vertical. Positive motion is downward at the horizon. This value will normally change slowly as you track a source - it is part of the ``focus curve''. The UIP's FOCUS command allows you to specify at what times the computer will be allowed to update the secondary's position. See the UIP's online help for FOCUS to get a description of the various updating modes that are available.
THETA - Secondary Mirror Theta Position
For the secondary mirror, theta is rotation about the optical axis. It is measured in degrees. The chop angle follows this rotation - it should always remain at 90 degrees to produce an azimuth chop. You may change this angle with the UIP's THETA command, but if you do so, the telescope's efficiency may drop.
FOCUS - Secondary Mirror Focus (Z) Position
This is the motion of the secondary mirror along the optical axis, which is normally called focus. It is displayed in mm units. This value will normally change slowly as you track a source - it is part of the ``focus curve''. The UIP's FOCUS command allows you to specify at what times the computer will be allowed to update the secondary's position. See the UIP's online help for FOCUS to get a description of the various updating modes that are available.
Y OFFSET - Secondary Mirror Y Position Offset
This is the distance, in millimeters, that the secondary should be offset from the focus curve, in the Y direction. Default values for this offset are loaded with the UIP's POINTING command, along with the ``Fixed Offsets''. This value can be set manually with the UIP's Y_POSITION/OFF= command. Note that setting the offset with the Y_POSITION/OFF= command does not result in the secondary mirror immediately moving. A FOCUS command must be issued to actually move the mirror.
FOC OFFS - Secondary Mirror Focus Offset
This is the distance, in millimeters, that the secondary should be offset from the focus curve, in the focus, or Z, direction. Default values for this offset are loaded with the UIP's POINTING command, along with the ``Fixed Offsets''. This value can be set manually with the UIP's FOCUS/OFF= command. Note that setting the offset with the FOCUS/OFF= command does not result in the secondary mirror immediately moving. A second FOCUS command must be issued to actually move the mirror.
FOC MODE - Focus Update Mode
This field tells you when the secondary mirror will be adjusted to follow its focus curve. The default is STEALTHY, which means that the secondary will be adjusted only when the alpha tells the antenna computer to adjust it. That will happen after each OO_SCAN or CHOP_SLEWY cycle is completed. See the online help for the UIP's FOCUS command for a description of the available focusing modes.
BSW - Beam Switching Mode
This field shows you the current beam switching mode, which can be CHOPPING if you are chopping the secondary mirror, or NOT CHOPPING if you are in regular position on/off mode.
Barom - Barometric Pressure
This is the current air pressure, in millibars. It is measured at a little weather station in the dome, near the shutter. This value is updated every 10 seconds, and is used in calculating the refraction correction.
Temp - Celsius Temperature
This is the current air temperature in degrees C. It is measured at a little weather station in the dome, near the shutter. This value is updated every 10 seconds, and is used in calculating the refraction correction.
Humid - Relative Humidity
This is the current relative humidity, in percent. It is measured at a little weather station in the dome, near the shutter. This value is updated every 10 seconds, and is used in calculating the refraction correction.
If this number is blinking, if means that the humidity is so high, water may start condensing on the telescope. You should frequently check to see if this is happening - once the telescope gets wet, the telescope's efficiency drops rapidly and it is almost impossible to dry the thing off until the dome warms up in the daytime. Close the dome if water starts to condense on the telescope. The humidity reading saturates at about 115-117%. If it gets that high you should close the dome immediately whether or not you can detect condensation.
Tau 225 - 225 GHz Tau Measurement
This is the opacity at 225 GHz. It is measured at roughly 10 minute intervals by a dedicated radiometer located on the roof of the shed. In very poor weather, the radiometer occasionally gives junk readings equal to, or less than zero. Such readings are not shown on the antenna display, so the display might not be updated at regular intervals during poor weather, or in the afternoons.
A more elaborate display of atmospheric opacity at both 225 GHz and 350 micron is available on our web-site .
AT - Tau Time
This is the Universal Time at which the currently displayed 225 GHz opacity was measured.
WIND PK - Peak Wind Speed
This is the maximum wind speed (in mph) measured during the last 15 minutes at the JCMT. If this value exceeds 50 mph, you MUST close the shutter!
AT - Wind Speed Timestamp
This is the time at which the peak wind speed was logged. The peak listed is the peak within a 15 minute window, so the time displayed here is not the exact time when the maximum speed gust occurred, but rather the time at which the 15 minute window started.
TLENGTH - Dome/Telescope Relative Position
This field displays the value of the LVDT that measures the position of the dome relative to the antenna. It is normalized so the the full travel of the LVDT is -1.0 to 1.0. If this value approaches 1, the antenna computer will idle itself, and you won't be able to move the telescope or dome. You will need to re-align the dome and telescope before you can observe. See dome/shutter related section in the CSO trouble shooting Guide on our web for detailed instructions.


2.4 Backend Display

The program in the backend computer which runs the AOS produces a real-time display of the AOS data. By default, this display appears on puuoo's monitor in the control room , but it can be re-directed to another X window display either on the summit or elsewhere (see the online help for the AOS command's /DISPLAY= qualifier). Examples of the types of display that will appear are shown in this section.

This display is produced when a temperature calibration scan is taken. The Tsys value is calculated using the data from such a scan, and is updated on this display. The "Problems:" region of this display is blank in this example. Any "Problems" that appear in amber are informational messages, and don't indicate anything serious. Any "Problems" that appear in red indicate conditions that will either corrupt the data, or prevent data from being taken at all.

This display shows the output of an OO_SCAN scan. The display will be updated as integration takes place. When the scan is complete this display will show a spectrum which is identical to the one stored in the CLASS data file.

The attenuation reported is the setting of the AOS's programmable attenuator. If the value is 0 or 31, that indicates that the IF power level is either too low or too high for the AOS to handle.

The Maximum, Minimum and RMS are all in temperature units (TA*) unless no valid calibration scan is available (in which case the message "No valid Cal. scan" will appear in place of the system temperature. When no baseline is active (as in this display), the RMS is calculated over all channels, even if there is a signal present (as there is here between channels 480 and 560). The only exception to this is the display for the 1.5 GHz AOS. Currently the Observatory's IF bandwidth is 1 GHz, so the edge of a spectrum from the 1.5 GHz AOS contains only noise. These noise channels are neither displayed nor used in the RMS calculation.

This display was produced during a CHOP_SLEWY scan. In most ways it is identical to the OO_SCAN display. However little green circles turn on and off as the secondary mirror chops. You should not be concerned if the little green circles do not appear and disappear with perfect regularity, or if the green dots do not appear and disappear simultaneously in several AOS windows which are simultaneously integrating. This display is produced in an X window, and it is not possible to control precisely when a feature will appear or disappear in an X window.

The green ``99'' is a measurement of the chop duty cycle. More precisely, it is the percentage of AOS data that is flagged as good by the Programmable Window Comparator. If it drops below 50, it will turn red, and you should try to do something to improve the chop duty cycle. Things you can try include:better tuning of the chopper; chopping at a lower frequency; reducing the chopper throw; increasing the positional tolerance level.

This display was also produced during a CHOP_SLEWY scan. In this case an AOS baseline window was active. These windows are usually introduced to allow pointing using a spectral line. The linear baseline is fitted to the channels shown in green. By default, the FIVE_POINT command will integrate all the white channels (all channels between the baselines), but this behavior can be overridden by qualifiers to the FIVE_POINT command. When a baseline is active, the RMS is calculated only over the green channels. The baseline shown in the display was specified by the command
UIP> AOS 10 300 450 580 700

This display was produced during an OTF_MAP. Each map cell is displayed individually. The cells displayed in white have spectra produced using two OFF integrations - they are identical to the spectra stored in the data file. The green spectra are from the row currently being scanned. The will be re-drawn in white, and stored in the data file after the OFF integration is taken at the end of the row.

Note that the vertical scale in each cell is independent of all other cells, and calculated to just fit the spectrum's data range. One side effect of this is that the cells with no signal appear to be noisier than those in which a signal appears. This is normal, and unavoidable, behavior.

This plot shows a ``Reticon'' display. It is simply a plot of the raw data from the AOS's reticon detector. The scale is inverted - low abscissa values correspond to high power. This display is sometimes useful for diagnostic purposes, or just to examine the shape of the IF bandpass. This display is turned on with the UIP command
UIP> RETICON.
It may be turned off by issuing the command
UIP> NO_RETICON.

One other useful program that used to run on the backend computer is orrery , which shows the real time (within 20 min) sky positions of your program source, available planets, CO pointing stars, other known continuum sources, Galactic plane, etc. Pull-down menu on the display allows you to configure what you want to display, and by clicking on a source a drop-out window will tell you what we know of the source, it's size, flux densities, and spectral line temperatures measured at CSO. Now the program is run from hapuan or kilauea. You can start the orrery on the Solaris boxes UIP by

hapuna% orrery -display puuoo:0.


2.5 Where Is That File?

The VMS operating system supports tree structured file directories. This means that important files can be hard to find. Here are where some of the important ones are located. Don't mess with any of these files without talking to Richard Chamberlin first. This information is included for completeness rather than that you will need it.


2.6 Taking Your Data Home

There are a variety of ways you can take your data home. We have three DAT magtape drives one each on Alpha1, Poliahu, and Hapuna, respectively). Also, our internet connection is usually fast enough to transfer a full night's worth of data in a few minutes. Please do not remove your data files from alpha1 after you have sent them home. You are encouraged to remove any files of temporary nature though. After you leave the observatory, your data will remain on the VMS machines for quite some times (up to one year), depending on the demand on disk space but also on the size of your data file(s). The data is archived to tapes on a regular basis, and is being mirrored constantly between two identical SCSI drives on Alpha1. When files are removed from your home directory, they are placed under BIGDISK:[tmp.usrname] for some extended period and eventually deleted.

Spectral Line data are also archived in a SYBASE database. If all copies of an original data file have been lost (a very unlikely event), the data can be retrieved from this database. But that's a big hassle.

2.6.1 Transferring Data Over the Internet

This is the most sensible way to transport data home, for most observers. The standard method of transferring data over internet is using FTP. Let's assume that your data file is called [SMITH]25DEC94.DAT , and you wish to transfer your data to a computer whose internet address is jach.hawaii.edu. The following dialog shows how the file can be transferred. Comments are preceded by an exclamation point.
$ FTP jach.hawaii.edu
JACH.HAWAII.EDU>login
Username: smith
Password: ! Your password is not echoed
JACH.HAWAII.EDU>bin ! Transported in "binary" mode
Type: Image, Structure: File, Mode: Stream
JACH.HAWAII.EDU>put 25dec94.dat 25dec94.dat
JACH.HAWAII.EDU>quit
If the target machine (jach.hawaii.edu in this case) happens to insist on communicating with remote hosts through secure shell (ssh) by refusing remote ftp and telnet requests, you would need to do the data transfer on one of our Solaris hosts, say Hapuna:
hapuna% cd /user_vax/smith
hapuna% scp 25dec94.dat smith@jach.hawaii.edu:/home/smith

2.6.2 Putting Data on Tape

If you really wish to go home with your data on a DAT tape, you can do that on the Alpha1 or Poliahu if you have a VMS machine back home to read the tape, or on Hapuna for UNIX hosts. Currently the name you should use for the tape drive is MKB300: on Poliahu or MKA100 on Alpha1.

On Alpha1 or Poliahu (your account is shared among the VMS hosts, which currently include one VAX (Poliahu) and two Alpha's (Alpha1 and Alpha2)), you would want to make a ``BACKUP Saveset''. This format has lots of redundancy, so a small number of tape errors will probably not corrupt your data. The Saveset is written with the VMS BACKUP command, and there is online help available for the command. Also, help can be found in volume 4A of the big orange VMS manuals in the computer room. The following example illustrates how to write several files to a Saveset.

First, insert a blank tape in the DAT drive $ init mkb300: tape ! This wipes out anything on the tape. $ mount/for mkb300: $ backup/ignore=label *DEC94.DAT MKB300:DEC94.BCK/SAVE $ dismount mkb300:
The above backup command puts all files ending in DEC94.DAT into a saveset called DEC94.BCK on the tape.

There may be cases when you have data (or other files you would like to take with you) in more than one directory or even on more than one disk. In this case the easiest way to back them up is to write yourself a command file like the one below (but you can type this in too if you want, the syntax is the same):
$BACKUP/LOG/VERIFY/IGNORE=LABEL -
/LIST=BACKUP.LIST USER:[RTM.MAR94]*.*.*,-
USER:[DBENFORD...]*.*.*,-
USER2:[DBENFORD...]*.*.*,-
USER2:[HUNTER...]*.*.*,-
LOG_DIR:*.*.* -
MKB300:DATA.BCK/SAVE
This procedure backs up data from the USER and USER2 disks as well as from the LOG_DIR directory, including complete directory trees. It takes all versions of all files in the directories, to get only the latest version use *.*; in the file specification. It produces a listing file called BACKUP.LIST in the directory where you started it from and writes a saveset called DATA.BCK on a DAT tape. The /VERIFY qualifier causes it to read back the data written to the tape and compare with the files on disk after it is finished writing.

On Hapuna, the DAT tape drive is at /dev/nrst4. To back up your data files to tape:
hapuna% cd /user_vax/smith
hapuna% mount /dev/nrst5
hapuna% tar cvf /dev/nrst5 *dec94.dat

2.6.3 Writing a FITS File

Our data reduction software comes from the Groupe d'Astrophysique de Grenoble (hereafter GAG). One of the programs in this suite, CFITS converts CLASS format files into FITS. Start the program by

$ CFITS
Read in you data file(s) in the normal CLASS way, with FILE IN and FIND/ALL (assuming you want all the scans). Insert a tape into the tape drive. Type
CFITS> MOUNT MKB300:
change the tape device name to /dev/nrst4 if you are on hapuna. After several seconds it should say it has done so successfully.
CFITS> WRITE *
- this will write out all the scans read in.

2.6.4 Dumping the Data as ASCII Text

It is also possible to write your data out from CLASS in ASCII format using the DUMP command. This is really an act of desperation, but we've had observers do it... There is help on the DUMP command within the CLASS manual.


2.7 Background Processes on Alpha1

There are several processes run on alpha1 that are not attached to any terminal. They are started when the the antenna computer is restarted, or when SHARC or an AOS is the active backend. Normally they operate without any user intervention. These processes are the background processes. If things have just stopped working, the chances are good that one of these processes is messed up.

The process ANT_MCP is the process which handles communication between alpha1 and the antenna computer. It makes sure that only one process can be sending commands to the antenna computer at any given moment, and it routes messages from the antenna back to the appropriate job. If an unsolicited message comes from the antenna computer, it will be printed on the terminal running the UIP (hereafter called the system console). If a job sends a message to the antenna computer that results in the antenna computer sending a response more than five seconds later, the response will be considered unsolicited, and will be routed to the system console (if there is one), not the appropriate job. (Messages logged on the system console are also saved in the operator log located in SYS$MANAGER. However, there is no system console on alpha1 and the existence of operator logs is somewhat unpredictable at best).

Dwncvtr Client is the process that accepts commands from the UIP, and sends them to the Downconverter, which is controlled by the backend computer.

AOS #n Client accepts commands from the UIP, and sends them to the nth AOS. <AOS n EKG> exchanges a message with AOS n every 5 seconds, to check if the AOS process on in the backend computer is still alive. If <AOS n EKG> detects that the AOS nis dead, it kills all other processes on alpha1 which are associated with the AOS, and sends a swan song to the system console. <AOS n Errors> is used by the backend computer to report any error conditions existing in the AOS n to the system console. <AOS n E. Flag> sets the appropriate event flag when AOS n completes an integration phase. <AOS n Scans> accepts the scan data from the AOS n, and writes to a data file. Most of these processes have SHARC mode analogs, with SHARC substituted for AOS n in the process name.


2.8 Printers

In the computer room there are two printers (HP Laserjet and HP color Inkjet) served out of puuoo. Printer queues are set up on various computers to access these two printers on Summit. On the Unix machines (hapuna, kilauea, and puuoo),
lpr filename
sends the file to the laser printer while
lpr -Pdj filename
points to the color inkjet. On the VMS machines (alpha1, alpha2, and poliau),
print/que=lw filename
sends the file to the laser printer while
print/que=lwc filename
sends the file to the color inkjet printer.

In the CSO office at Hale Pohaku, there are also two printers (HP laserjet and HP color inkjet) served by the Linux workstation ono. Again, the laser printer is the default (``lp'') and ``dj'' points to the color inkjet. These two are accessible from any of the Summit machines with queue names of ``onolp'' and ``onodj'' respectively. Similarly, the two printers at our Hilo office are accessible from any of the Summit machines vis queue names ``hilolp'' and ``hilodj''.

Ruisheng Peng 2002-01-18