Keywords have been defined to match those used by FITS as far as possible, as this is the standard output file format, and to maximise consistency through the system.
As noted above, rigorously following the FITS format for each keyword line is not desirable, i.e. that the ninth character must be an = sign, that the tenth character is left blank for legibility, and that the (optional) parameters taken by the keyword start at the eleventh character in the line. However, each keyword has to appear on a new line and only one keyword per line is allowed.
Characters are ASCII. The examples shown are generally in uppercase, matching the FITS standard, but the command parser must be insensitive to case for the key words, but not for some parameters, such as personal or file names, where the case must be preserved.
Comments are allowed only on a line starting with the keyword COMMENT or a `//'. Following comments on subsequent lines must all start their line with either COMMENT or `//'. After the end of a keyword and parameter definition a comment may be added to that line indicated by `//'.
Any given keyword may be needed by one or more components of the NCCS, and is classified in this way:
Keywords may not appear in a totally random order in the input file. The following indicate where in the input file a keyword, if present, is valid:
A keyword may be valid in several sections. This is indicated by a comma separated list in [ ] as, for example, for the keyword COMMENT, which may be anywhere in the input file: [ s, cb, o, i, cat ] .
Most keyword parameters may be overwritten in any scan, with the most recent parameters given being the active ones. This is further elucidated in the section on Parser Logic.
This keyword itself is optional, but a setup section is mandatory i.e. there has to be a SETUP section at the start of each input file. This is thus implicitly the first line of the file and defines a section for setting parameters common to a set of scans. This keyword takes no parameters. It is allowed only once per input file and should precede all other sections. Parameters for an individual scan which conflict with what is in the SETUP would be discarded after that scan, as the parameters in SETUP are reapplied at the start of every scan in the file. Parameters that would typically be placed in this section would be OBSERVER, CONF and ENDCONF and DEFCONF, SCANTYPE, CATALOG.
Optional, as SETUP is automatically terminated by the first occurence of OBJECT (but not by CONF... ENDCONF). Used to denote the end of the SETUP section containing globally applicable keywords.
Optional. Define a group of keywords to be used repeatedly in the subsequent observations. The parameter taken is a character string that uniquely "name"s (case insensitive) this configuration. The "name" is then given as a parameter to a later USECONF command to indicate that this configuration is to be used in the observation of a particular object. The text between CONF and ENDCONF is pasted in wherever USECONF "name" is found later. CONF may only appear in SETUP and must occur before any DEFCONF that uses it.
An example of its usage would be:
CONF = 18NA // receiver name, reference for later use RESTFREQ= 1660E6 // define the front end to use INSTRUME= NA // define the instrument to use ENDCONF // end of this configuration block ... OBJECT Hydra A // observe calibrator USECONF 18NA // paste in text from CONF 18NA SCANTYPE STEP // use standard stepping scan
Optional. Marks the end of a CONF block of commands. If ENDCONF is not explicitly present at the end of a CONF block, the block will be terminated automatically by the next occurrence of ENDSETUP, CONF, DEFCONF or OBJECT.
Optional. Paste in the block of commands specified previously by CONF = name ... ENDCONF. If USECONF is specified with multiple parameters, the CONF blocks are pasted in and used sequentially in the given order. USECONF may only occur within an OBJECT i.e. not in SETUP.
Optional. Paste in, by default (unless a blank USECONF appears in the object), a block of commands specified previously by one or more CONF ... ENDCONF blocks. e.g. DEFCONF conf1 conf2 conf3 DEFCONF, if present, must appear in the SETUP section after the definition of the CONFblocks mentioned in DEFCONF i.e. here CONFblocks called conf1 conf2 and conf3.
Mandatory for actual observing. Identification of the object in some form, such as a name (e.g. Hydra A or 0915-11). If the object's coordinates are to be obtained from a catalogue, the name must be recognisable, i.e. the characters must match the name or its alternatives as given in the catalogue.
The keyword OBJECT is used to signify the start of the definition of the parameters needed for a new scan, or set of scans using different receivers, on this object. When used in a catalogue, alternative names are to be comma-delimited as they may naturally contain spaces, eg "Hydra A".
Optional. Can be used to specify the end of a set of parameters for the scan(s) of an object. This is normally terminated anyway by the next OBJECT keyword or end of intput file.
Optional. Comment line, ignored by parser, as are blank lines. Currently a comment stretching over multiple lines must have each line beginning with COMMENT.
Mandatory. Name of the principal investigator. Only allowed in SETUP.
Optional. Name of on-site person responsible for the observing if the OBSERVER is not a staff member. Only allowed in SETUP. The name should match their e-mail name within HartRAO to facilitate messaging.
Mandatory. Short name for the observing project, taken from the observing proposal. Specified in section 6.10 of the "NCCS Requirements and Specifications". Only allowed in SETUP.
Mandatory. Number of the observing proposal, allocated on acceptance of the observing proposal. Specified in section 6.10 of the "NCCS Requirements and Specifications". Following the GBT model, it is used to create the directory into which the output data files will be placed. Format: year.3-digit number, eg 2003.012. Only allowed in SETUP.
Mandatory. Defines the type of scan (observation) and hence the parameters that are required to define it fully. In essence, the SCANTYPE defines the observing program or algorithm that will be called by the scheduler to execute the scan.
Options are:
Common observing program parameter. Mandatory for real observing. Standard or centre frequency to be used. Unambiguously defines the receiver system to be used. The specified frequency is checked against the upper and lower frequency limits each receiver within the observing method specific part of the parser (i.e. the implementation of this is the responsibility of the author of the observing programme). If the receiver is tunable, it will be set to the specified frequency. If not tunable, it will operate at the standard frequency defined in SYPARM.
RESTFREQ can be used within the SETUP section only within a CONF ... ENDCONF block. Within an object each occurrence of RESTFREQ gives a separate scan on this object.
Units of frequency are Hertz (FITS standard). Multiple RESTFREQ + INSTRUMEs can be defined within a CONF ... ENDCONF block, and there can be multiple instruments connected to a receiver.
Receivers are defined to be dual, providing opposite senses of polarization, normally left and right circular. Hence if it is possible to set the rest frequency independently for the two channels, then we will need to use the form (currently not yet implemented):
RESTFREQ LEFT 123.456e6
RESTFREQ RIGHT 123.654e6
If RESTFREQ = 0 then no receiver is specified; the telescope can POSITION and TRACK, without pointing corrections or beam offsets added, but no data can be acquired. This option allows the telescope to be parked at or track any desired position, e.g. zenith or a position to drain off water, before setting up observing.
If observing is wanted with more than one receiver operating simultaneously, this will need to be specified, perhaps by giving more than one rest frequency, where the first specified defines the primary system, and the other(s) the secondary receivers (not yet implemented in the parser). The beam offsets applicable to the first receiver specified in this way would be used. Except in the case of the dual-SX system, the secondary receivers would point at different positions in the sky to the primary receiver. More than one receiver operating simultaneously is envisaged as a requirement for continuum mapping.
Mandatory for spectra. Optional for continuum radiometry and pulsar timing. Units are Hz, following the FITS standard for frequency. The single parameter defines the filter bandwidth that is to be used.
The available IF filters for the signals to the radiometers and pulsar timer are 32, 16, 8, 4 x10^6 Hz.
If the bandwidth selected is narrower than the narrowest available IF filter, the narrowest installed IF filter will be selected.
If the bandwidth requested is larger than the widest IF filter, the signal will be unfiltered.
If not specified for continuum observing or pulsar timing, the signal will bypass the IF filters and the bandwidth will be determined by other receiver and instrument characteristics.
For spectroscopy, the bandwidth selected may be narrower than the narrowest IF filter installed in the signal path to the total power radiometers used for calibration. The spectrometer bandwidth is set by the DAS video filtering and is 32, 16, 8... 0.0625x10^6 Hz. The IF filtering will apply to the signal going to the total power radiometers used to calibrate the spectrum amplitude.
Only used for continuum observations. Common observing program parameter. Mandatory if RESTFREQ is not zero and SCANTYPE is not SPECTRUM or PULSAR, ie the scan is continuum radiometry of some form, as three types of continuum radiometer are defined. Specifies the instrument to be attached to the receiver operating at RESTFREQ. The name INSTRUME is used rather than BACKEND for consistency with the FITS standard.
Defined INSTRUMEnts are:
The first letter of the INSTRUMEnt is sufficient to identify it uniquely, though more are likely wanted for clarity, at least for human parsers. As noted above, the last two types are strictly redundant.
There are four radiometers. One pair can be configured for either NA or TP, and the other pair are used for DICKE mode. A pair provides for Left- and Right-circular polarization. All the radiometers are set to total power configuration, as NA and Dicke are now carried out in software.
The type of radiometer selected also defines how the receiver will be configured, as this must match the instrument configuration.
Defining SCANTYP = SPECTRUM automatically implies INSTRUME = SPECTROMETER, that secondary backends, total power radiometers, will also be connected in order to calibrate the signal amplitude, and that the receiver will be in single feed, total power mode i.e. dual feed receivers will be locked to a single feed and that any noise diodes used for noise-adding gain stabilisation will be switched off. In addition, the narrowband intermediate frequency (IF) system will be used, together with the tuneable local oscillator (LO) system.
Likewise, defining SCANTYP = PULSAR automatically implies INSTRUME = PULSARTIMER, and the receiver is in single feed, total power mode, and total power radiometers are attched for calibration.
Optional. Defines a source number for the object. Should be unique within the input file, or misidentification can occur. Parameter is integer or integer mixed with letters. Can be used, for example, to define where to start observations in an input file, e.g. "start at source 25" or "start at source 11B", the alternative being "start at object HYDRA A". From start of file would normally be numbered 1, 2, 3..., but not necessarily so. Particularly useful when an object name is used repeatedly in a file, thus becoming ambiguous as a start pointer.
Optional. Defines the name of a catalogue (including its absolute directory path) in which some or all of the necessary information about the object is to be found. Catalogues must have standard formats, to be defined. I suggest that we use the input file format, using keywords with parameters. This permits full interchangeability, in the sense of cut and paste, between the information in input files and in catalogues. (Comments may not be permissable with this keyword owing to possible confusion of the prefatory `//' with the `/' use for directory paths.)
We will likely have a standard 'catalog' directory in which catalogs should be placed, in which the parser will search first to find the specified catalog. If not found there, the parser searches the current working directory. The information put into catalogues must be object specific and not observing specific.
Only used for continuum observations. Optional for calibrators. Parameters are the coefficients used to calculate the flux density of the object at the observing frequency.
Only used for continuum observations. Optional for calibrators. Parameters are the lower and upper frequencies in Hz between which the flux computed from OBJFLUX parameters is valid.
Optional. Reference or source of information. (standard FITS)
Optional. Specifies a subdirectory in which the output file will be written. As implemented currently, the output file name is created automatically using the date and time at which the output file was written, with the local observer's name and the source name inserted, for example: 2003d198_11h08m48s_Spec_mikea_G285.26-0.05.fits.
The output file is written to directory 'data', subdirectory 'local_observers_name' as specified by keyword OBSLOCAL, sub-sub-directory 'outfile_name' as specified by keyword OUTFILE.
Comments may not be permissable with this keyword owing to possible confusion of the prefatory `//' with the `/' use for directory paths.
Optional. Defines the coordinate system. For more information on coordinate types see the papers on Representations of celestial coordinates in FITS, by E W Greisen and M Calabretta, at http://www.atnf.csiro.au/people/mcalabre/WCS/.
Base coordinate systems are:
Note that STEER as currently implemented does not use EQUATORIAL as a coordinate type, but instead implies it by using the EQUINOX (see below) as the coordinate types APPARENT, MEAN, B1950 and J2000. See Steer.h.
Technically COORDSYS may be redundant, as it is implied by the key words used to specify the "special point", but may improve human readability. The celestial position specified by these coordinates is mapped into the origin (PROJTYPE=CAR) or pole (PROJTYPE=SIN or TAN) of the "native coordinate system", as defined in the WCS/CCS documentation.
Coordinates for bodies in the solar system, such as the Sun, moon, planets, comets etc. must be calculated in real time or obtained from the output of a program such as the JPL solar system ephemeris.
For the Sun, Moon and planets, this has now been been built into the NCCS so that specifying the object name in the input file is sufficient and the current coordinates of the object will be returned. Comets are still to be implemented at 2004/08/25.
The JPL solar system ephemeris, at http://www.gb.nrao.edu/ rfisher/Ephemerides/ephem_descr.html describes how to obtain and use this software for computing the positions of solar system objects.
Ephemerides for Earth-orbiting satellites can also be used. This was developed for program 'Holography'. In this case the ephemerides are entered in a standard two-line format, for example:
EPHEM1 1 25491U 98056A 04231.97760678 .00000106 00000-0 00000+0 0 8635 EPHEM2 2 25491 0.0246 50.1443 0003801 95.3588 190.0822 1.00272434 21538
Used by parser, scheduler, observing program. Mandatory if keywords RA, DEC are used (COORDSYS= EQUATORIAL). Defines the equinox (previously known as the EPOCH in FITS) for equatorial coordinates. Following the FITS standard, the keyword takes the parameters:
Mandatory for COORDSYS= EQUATORIAL; longitude-like coordinate of a "special point" (see CRVAL1 in WCS/CCS documentation). Defines the right ascension of the object. If three numerical values are given, they are assumed to be hours minutes and seconds, e.g. 09 15 23.54. Can also be written with postfix notation as 09h15m23.54s. If one numerical value is given, it is assumed to be in decimal degrees, e.g. 93.231 or 93.231d in postfix notation. If RA, DEC are specified then COORDSYS= EQUATORIAL is implied if it was not specified, but EQUINOX is mandatory.
Mandatory for COORDSYS= TOPOCENTRIC; longitude-like coordinate of a "special point" (see CRVAL1 in WCS/CCS documentation). Defines the hour angle of the start of a scan. Parameter handling by parser: Units are decimal degrees if a single value is given with no postfix symbol, e.g. 123.456. Can be specified in decimal hours using postfix notation as 3.15h. Can be specified in hours, minutes, seconds only by using postfix notation with no spaces e.g. 3h or 3h17m or 3h17m10s. If HA, DEC are specified then COORDSYS= TOPOCENTRIC is implied if it was not specified.
Used by scheduler and observing program. Mandatory for COORDSYS= EQUATORIAL or TOPOCENTRIC; latitude-like coordinate of a "special point" (see CRVAL2 in WCS/CCS documentation). Defines the declination of the object. Parameter handling by parser: If one numerical value is given, it is assumed to be in decimal degrees, e.g. 13.231 or 13.231d in postfix notation. If three numerical values are given, they are assumed to be degrees minutes and seconds, e.g. -11 01 20.7. Postfix notation can be used, e.g -11d01'20.7". For negative declinations, a minus sign must be present. Care must be taken with declinations between 0 and -1 degrees.
Mandatory for COORDSYS= GALACTIC; longitude-like coordinate of a "special point" (see CRVAL1 in WCS/CCS documentation). Defines the galactic longitude of the object. If GLON, GLAT are specified then COORDSYS= GALACTIC is implied if it was not specified. Parameter handling by parser as per DEC.
Mandatory for COORDSYS= GALACTIC; latitude-like coordinate of a "special point" (see CRVAL2 in WCS/CCS documentation). Defines the galactic latitude of the object. Parameter handling by parser as per DEC.
Mandatory for COORDSYS= ECLIPTIC; longitude-like coordinate of a "special point" (see CRVAL1 in WCS/CCS documentation). Defines the ecliptic longitude of the object. If ELON, ELAT are specified then COORDSYS= ECLIPTIC is implied if it was not specified. Parameter handling by parser as per DEC.
Mandatory for COORDSYS= ECLIPTIC; latitude-like coordinate of a "special point" (see CRVAL2 in WCS/CCS documentation). Defines the ecliptic latitude of the object. Parameter handling by parser as per DEC.
Mandatory for COORDSYS= HORIZON; longitude-like coordinate of a "special point" (see CRVAL1 in WCS/CCS documentation). Defines the azimuth measured in degrees clockwise from north (does this match the STEER definition?). If AZIMUTH, ALTITUDE are specified then COORDSYS= HORIZON is implied if it was not specified. Parameter handling by parser as per DEC.
Mandatory for COORDSYS= HORIZON; latitude-like coordinate of a "special point" (see CRVAL2 in WCS/CCS documentation). Defines the altitude measured from the horizontal. Parameter handling by parser as per DEC.
Longitude of the celestial pole in the "native coordinate system", as defined in the WCS/CCS documentation. The function of this parameter is to rotate the observation field about the "special point". This would normal only be used with the azimuthal projections ("SIN" and "TAN") and is specified in degrees. Parameter handling by parser as per DEC.
Used by scanning program. Projection type.
Until Steer is modified we will have to stick to "PROJTYPE=CAR".
The three angles (RA et al, DEC et al, and LONGPOLE) are used to construct the "EULER" angles currently used by Steer. The construction depends on the "PROJTYPE":
JJ envisages that, in time, we (JJ!) will change the Steer server to accept the parameters "CRVAL1", "CRVAL2" and "LONGPOLE" rather than the greek entities.
Offset added to longitude-like coordinate. Parameter handling by parser as per HA.
Offset added to latitude-like coordinate. Parameter handling by parser as per DEC. LONOFF and LATOFF are typically used to refine the position of an object or to check beam offsets.
These keywords define scheduling constraints and some simple repeat options.
More complex control structures can be defined if necessary.
The start time and end time are made up using two keywords each, STRTDATE , STRTTIME and ENDDATE , ENDTIME respectively. STRTDATE and ENDDATE are mandatory whereas the STRTTIME on the STRTDATE and the ENDTIME on the ENDDATE default to 0 hrs UT and 24 hrs UT respectively, if not present.
Used by scheduler. Optional. Specify the order in which the objects in a file are to be observed. Possibilities are:
- linked sequence of scans. A source that has an HALIST or a STRTSDRL (start siderial time) may not be LINKED to a previous source, though the following sources may be LINKED to it.
Used by scheduler. Optional. Priorities available for single-dish observing are, from highest to lowest:
The VLBI software is able to override all single-dish observing. The default priority is foreground.
Used by parser. Optional. Specifies the object or source no. with which observing must start. Must match either the object name or the corresponding source identifier if specified. Subsequent observations continue sequentially and wrap around to the start of the file and on to end with the object preceeding the one given for STARTAT. If there is a STOP in the file then observations STOP with the object preceeding the STOP.
Used by scheduler. Mandatory. Start date or epoch for observations. The start date can be written in various formats:
When coupled with INCREMNT, this permits observations to be scheduled weekly, for example. A more complex example is given by any object which is to be observed only when certain behaviour is predicted to occur - this would not be synchronised to UT, but to the ephemeris of the behaviour. Circinus X-1 is one such case, for which the Julian date option would be used in order to specify the flare epoch as accurately as possible.
Used by scheduler. Optional. Units are decimal days. For weekly monitoring, a single value of 7 is sufficient. For objects such as Cir X-1, the period of the behaviour is used, with STRTDATE and ENDDATE bracketing the monitoring period if it is longer than one day. For Cir X-1, to observe from 2 days before the flare epoch to 4 days after, the parameters would be:
where 16.605793 is the flare period.
Note that RESTART DAILY has been implemented which uses the value supplied with INCREMNT to reschedule scans. See RESTART for more details.
Optional. Siderial start time. Parser handling of parameters as per STRTTIME. A scan wtih a STRTSDRL may not be LINKED to a previous source, though the following sources may be LINKED to it.
Optional. Specifies the Universal Time at which the observations are to start. Its use can be tied in to STRTDATE to specify a start date other than the current date. If STRTTIME is not specified, the start time will be 0h UT on the start date.
The start time parameters may be specified as:
Can also be specified as "SUNSET" or "SUNRISE". Whether this usage is applicable may depend on the receiver in use, so it should be defined when the receiver is defined by RESTFREQ + INSTRUME usually in a CONF ... ENDCONF block. If it is defined elsewhere in the input file, where it is not logically associated with a specific receiver, then it will be applied to all receivers. The default value is for no day/night constraint i.e. NIGHTIME flag set to 0. Requires JPL solar system ephemeris.
STRTTIME SUNSET automatically sets ENDTIME to SUNRISE and sets the NIGHTIME flag to +1 (i.e. observing at night) and STRTTIME SUNRISE automatically sets ENDTIME to SUNSET and set the NIGHTIME flag to -1 (i.e. observing in day time).
Used by scheduler. Mandatory. Specifies a date at which these observations are to end. The format is the same as for STRTDATE with the additional parameter `+x' where x is the decimal days after the start date that the observations should end. The latter automatically assigns the appropriate decimal part to the ENDTIME, which may be overwritten if desired. - Note that for this parameter the ENDTIME does not default to 24 hrs UT.
Used by scheduler. Optional. Specifies the Universal Time at which the observations are to end. Parameters are as for STRTTIME, but without the NOW parameter option. If ENDTIME is not present the end time defaults to 24h UT on the end date.
Can also be specified as "SUNSET" or "SUNRISE". Whether this usage is applicable may depend on the receiver in use, so it should be defined when the receiver is defined by RESTFREQ + INSTRUME usually in a CONF ... ENDCONF block. If it is defined elsewhere in the input file, where it is not logically associated with a specific receiver, then it will be applied to all receivers. The default value is for no day/night constraint. Requires JPL solar system ephemeris.
ENDTIME SUNSET automatically sets STRTTIME to SUNRISE and sets the NIGHTIME flag to -1 (i.e. observing in day time) and ENDTIME SUNRISE automatically sets STRTTIME to SUNSET and set the NIGHTIME flag to +1 (i.e. observing at night).
Used by scheduler. Optional. The associated parameter specifies the number of times the scan or set of scans at different frequencies is to be repeated in order to get data with the wanted signal-to-noise ratio. For example, eight spectra, each of 15 minutes duration, may be needed for a particular object; REPEAT would then be = 8. If omitted, REPEATS defaults to 1.
Used by scheduler. Optional. Implies that observing can restart from the beginning of the file. This keyword is normally placed at the end of the file, but if inserted before the end of an input file, scans after RESTART will not be scheduled.
RESTART can take the optional parameter 'DAILY'. This was implemented on 2004/06/28. The aim is to carry out repeated observations at a time interval of a day or more, and which are NOT specified by an HALIST. If RESTART is used without DAILY and without HALIST, scans of the object will be scheduled continuously while it is visible. However one often wants daily monitoring of an object, and this will usually be within a specified hour angle range which would depend on the declination of the object and the observing frequency. The parameter DAILY then reschedules the observing at intervals specified by the keyword INCREMNT, but only for the number of times originally specified, i.e. it will NOT run continuously while within the valid HA range. e.g.
strtdate 2004 01 01
strttime 00 00 00
enddate 2004 01 02
endtime 00 00 00
incremnt 1.0
... coupled with ...
restart daily // at end of source file
here does provide a daily increment, and the inserted scans will not
repeat continuously.
Optional. Implies that there is no further observing from this input file. It is redundant at the end of a file if RESTART is not specified, but if inserted before the end of an input file, it terminates observing from the file, and objects after the STOP will not be observed. The parameter ZENITH could be used optionally to park the telescope at zenith when the STOP is encountered (not yet implemented).
Used by scheduler. Optional. List of hour angles at which scans on this object should be carried out. If not specified, then any hour angle at which it is visible, or within HALIMIT if specified, is acceptable. The HALIST option is normally used for a source file containing a single object that is to be monitored more than once per day. Parameter handling by parser as per HA. An object that has an HALIST may not be LINKED to a previous object, but an object with an HALIST may have subsequent objects LINKED to it.
Used by scheduler. Optional. Absolute value of hour angle within which valid observations can be made. Object is not to be observed outside this hour angle range. Parameter handling by parser as per HA. Alternative forms could be defined if necessary, e.g. ALTLIMIT providing an altitude limit. The default value is the STEER limit.
Used by scheduler. Optional. Parameter in decimal degrees. Angular value of elevation above which valid observations can be made. Object is not to be observed below this angle.
Used by scheduler. Requires JPL solar system ephemeris. Optional. Angular distance from the Sun beyond which observations can be made. Units are degrees. If the angular separation is less than specified by SUNDIST, the object is not observed. Usable angular separations depend on the receiver system in use, so this parameter can take different values for each defined receiver, and should be defined when the receiver is defined by RESTFREQ + INSTRUME in a CONF block. If it is defined elsewhere in the input file, where it is not logically associated with a specific receiver, then it will be applied to all receivers. The default value is zero. Parameter handling by parser as per DEC.
Used by scheduler. Requires JPL solar system ephemeris. Optional. Angular distance from the Moon beyond which observations can be made. Units are degrees. If the angular separation is less than specified by MOONDIST, the object is not observed. Usable angular separations depend on the receiver system in use, so this parameter can take different values for each defined receiver, and should be defined when the receiver is defined by RESTFREQ + INSTRUME in a CONF block. If it is defined elsewhere in the input file, where it is not logically associated with a specific receiver, then it will be applied to all receivers. The default value is zero. Parameter handling by parser as per DEC.
Optional. Worst allowable weather condition which will permit useful data to be obtained. The three possibilities are CLEAR, CLOUDY and RAIN. The application of this keyword assumes that there are methods for determining the weather state. The default case is RAIN i.e. to run in any of the three weather conditions.
The 26-m telescope is a Cassegrain design with all receivers at the secondary focus. In general the shorter the wavelength at which a receiver operates, the closer it is placed to the geometric axis of the telescope. The efficiency falls off in proportion to the displacement in wavelengths from the axis. In addition, for off-axis feeds, the focal points do not lie on a plane but on a curved surface. To optimise the efficiencies of the receivers, they are primarily set up along a north-south line, and the subreflector can be moved up or down ("focussed") and its north-south angle ("tilt") changed. Prior to 2004 these to two movements were set with actuators driven by manual controls in the control room. In 2004, computer control of these functions is being implemented, and this will have to be accomodated in the NCCS software to permit engineering test observations.
For completeness, we note that in addition, some receivers can be manually moved up or down on their mountings at the secondary focus, in order to optimise their performance. This is normally a once-off operation carried out when the receiver is installed.
The feedhorn(s) of each receiver are pointed at the centre of the subreflector. For feeds significantly off the geometric axis of the telescope, tilting the subreflector through half the angle of offset minimises the phase errors across the aperture and hence maximises efficiency. When the subreflector could only be driven manually, this optimisation was only used for 18cm, where the feed is mounted externally to the Cassegrain cone. In this case, efficiency was improved by about 30 per cent. Computer control of the tilt and focus may permit such optimisation for other receivers.
The subreflector tilt and focus values normally used for each system is kept in the system parameter file (syparm), and for normal observing this is applied automatically and should not be specified by the user. These keywords are NOT needed for normal observing.
However for engineering test observations, the performance of the receiver at different settings of subreflector may need to be measured, using the key words specified below. It should be noted that the standard feed offsets (also kept in syparm) will then also not apply, and the object being observed will no longer be positioned in the centre of the beam. Observations offset at the NSEW halfpower points of the beam will need to be made to determine the pointing offsets and to correct the observed on-source antenna temperature.
The angle through which the subreflector can be tilted depends on the focus position of the subreflector - the lower the subreflector, the greater the angle through which it can be tilted without hitting the support structure. These limits will need to be built into the tilt and focus command validity checking algorithm to ensure that the computer does not drive the subreflector into the limits set with microswitches on the actual structure.
Focus position of the subreflector relative to the standard position for the receiver in use. Units are centimetres (not raw engineering units of readout). The sign is positive for movement away from the paraboloid main reflector and negative for movement towards the paraboloid. If no receiver has been specified (eg in a menu test program), the reference focus position is taken as the geometric on-axis focussed position of the subreflector, which would be defined as zero cm. For actual observing with a given receiver, the receiver must be specified before subfocus. Examples: 0 = standard position; +3.3 = 3.3 cm away from the paraboloid; -1 = 1 cm toward the paraboloid.
Tilt position of the subreflector relative to the standard position for the receiver in use. Units are degrees. The sign is positive for a tilt to the north (e.g. for 18cm receiver) and negative for a tilt to the south. If no receiver has been specified (eg in a menu test program), the reference tilt position is taken as the geometric on-axis tilt position of the subreflector, which would be defined as zero degrees. For actual observing with a given receiver, the receiver must be specified before subfocus to ensure that the correct reference value is used. Examples: 0 = standard position; +5.7 = 5.7 degrees to the north; -10 = 10 degrees to the south.
These now follow JJ's prescription, with the addition of radius for a circular scan.
x offset from special point of scan start. Parameter handling by parser as per DEC.
y offset from special point of scan start. Parameter handling by parser as per DEC.
x offset from special point of scan end. Parameter handling by parser as per DEC.
y offset from special point of scan end. Parameter handling by parser as per DEC.
Length of scan in seconds.
Optional keyword for drift scan. The single parameter for a drift scan is the scan length in right ascension of date. Units are degrees. Parameter handling by parser as per DEC. For a drift scan, if the distance is not specified, the default is the beamwidth to first nulls (from SYPARM or calculated) + 20 percent. This default depends on the receiver in use, as the beamwidth is frequency-dependent. Hence SCANDIST is tied to a particular receiver, so if multiple receivers are specified and the default scan length is not wanted, SCANDIST must be specified after each RECEIVER + INSTRUME definition. Apart from a fixed distance in degrees, given for example as 1.57 or 1.57d, SCANDIST can be specified as FN (between first nulls +20%) or SN (between second nulls).
Optional keyword for circular scan. The single parameter defines the radius of the circle, in degrees. Parameter handling by parser as per DEC. Alternatively, frequency-dependent values from SYPARM can be used, such as HP, FN, SN. If not specified, the RADIUS would be set to HP, the halfpower point of the beam.
Optional. Specify output coordinate system if different from projected. Keywords as per COORDSYS, plus EQUINOX if COORDSYS = EQUATORIAL.
Optional keyword for STEPing observations. Its parameters define the sequence of tracks to be taken, and are aliases for beam-dependent numerical (x,y) offsets. Defined positions in SYPARM are:
The step sequences used on the HP in the programs TNFPC, TNSTP and TNFQS, in this notation, were:
FNNACAL, HPNA, ONA, HPSA, FNSA, ZC, FNNB, HPNB, ONB, HPSB, FNSB
FNNCAL, HPN, ON, HPS, FNS
FNNACAL, HPNA, ONA, HPSA, FNSA, FNEA, HPEA, ONA, HPWA, FNWA, ZC
FNNCAL, HPN, ON, HPS, FNS, FNE, HPE, ON, HPW, FNW
FNNACAL, ONA, FNSA
Default scan patterns need to be decided upon, but any useful step pattern can be implemented using the STEPSEQ command.
These are maps observed as a single entity, like a step sequence. The small map keywords are based on the inputs used by MAPR3 on the HP1000. Scans are defined to be "vertical" ie in latitude at a fixed longitude.
COORDSYS (as defined previously) and corresponding keywords are used to define the coordinates of the map centre, and is mandatory. COORDSYS also defines the orientation of the map, eg if RA, DEC, scans will be in RA, DEC; if in Ecliptic longitude and latitude, the scans will be in ecliptic coordinates.
Note that for mapping the Sun and the Moon, the input signal level to the instrument must be computer controllable to avoid saturation. The first step in mapping the Sun or Moon (and perhaps all objects) is to track the centre of the object and measure the signal level, adjusting it to prevent saturation. This was done manually with the HP1000, but this is not acceptable for the NCCS.
Keywords specific to small maps are defined below.
Some tight linkage between the scheduler, the mapping procedure and Steer will be needed to implement the "SCANST" keyword, but perhaps this functionality is not needed in the scheduler. After some considerable thought and many changes of heart, JJ has come to the conclusion that time-critical observing, such as Skymap-like procedures, should be treated as a single observation by the scheduler, i.e. will hog the antenna. There does not seem to be any reason to include extremely specific functions into the scheduler that will only be used by a single observing process. In addition, there is no need for the scheduler to be involved in scheduling individual scans which cannot be interrupted anyway. JJ knows that this appears to moves away from the concept of "orthogonal coding", but the time-critical mapping JJ has in mind (the south pole region) is quite complex and specialized.
MG asks: Do all our readers agree with this? Scheduler shutdown just for JJ's maps?
Optional for small map. Map height in terms of projected coordinates (e.g. longitude, declination etc.) in degrees.
Optional for small map. Map width in terms of projected coordinates (e.g. latitude, right ascension etc.) in degrees. At least one of SIZELAT or SIZELONG must be set. If only one is set, the map is made square.
Optional for small map. Spacing of scans in longitude, in terms of projected coordinates in degrees. If not set, a default will be used based on the beamwidth at the frequency in use.
Optional for small map. Bin size in latitude, in terms of projected coordinates in degrees. If not set, a default will be used based on the beamwidth at the frequency in use.
Specify scanning in longitude or in latitude? Parameters? Appears to have been superceded by SCANDIR.
Optional for small map. Specifies direction(s) of scans. Implemented 2004/09/08. Parameters taken are LONGITUDE (i.e. scans in longitude-like coordinate only), LATITUDE (i.e. scans in latitude-like coordinate only) or BOTH (i.e. orthogonal scans in both longitude-like and latitude-like coordinates, to produce orthogonal scans suitable for "basket-weaving" data reduction). If SCANDIR is not specified, it's value is taken as being BOTH.
A SCANTIME (as defined previously) can be specified, as for any active scan. If not specified, a default value is used based on the beamwidth at the frequency in use, in order to get a suitable number of samples per beamwidth.
Mandatory for spectra of galactic objects (double). Parameter is the velocity with respect to the local standard of rest at which the spectrum is to be centred. Units are km/s. An alternative parameter will be used for solar system objects such as comets.
Mandatory for spectra (int). The single parameter specifies the number of correlator channels per input signal channel that the correlator must be configured for. Valid values are 1024, 512, 256 (1024 is only current implementation).
Optional for spectra (string). Defines the correlator configuration, ie left+right circular polarization (default), left only, right only, Stokes parameters IQUV from left+right circular polarization). SPCONF is not currently implemented.
Optional for spectra (double). The single parameter defines the frequency-switching offset that is to be applied to the second of the pair of spectra. Units are Hz, following the FITS standard for frequency. If SPFS is not specified and SPPS is zero, then a single scan will be done, without a reference spectrum. It might be useful to define a default parameter value for SPFS, namely if SPFS is given without a parameter, it defaults to half of the bandwidth specified by BANDWDTH.
Optional for spectra (double). Two parameters define the offsets in position that are to be applied to the second of the pair of spectra. The meaning of the parameters depends on the coordinate type that has been specified. If coordinates are galactic, offsets will be longitude, latitude, whereas if coordinates are equatorial, offsets will be RA, Dec. Units are decimal degrees. If SPPS is not specified, then SPFS must be non-zero, else a single scan will be done.
Mandatory for spectra (long). Total duration of one scan. Units are seconds. An observation normally comprises a pair of frequency- or position-switched scans of total duration SPTIME * 2. Used to set correlator parameters. Note that the MB correlator produces a new spectrum every five seconds, so that the actual scan length will be integer multiples of five seconds.
Optional for spectra (short, TRUE=non-zero / FALSE=zero passed to observing program by parser). Used by observing program to construct a set of 3 pairs of scans. Takes no parameters. If this keyword is present, obtain spectra of duration SPTIME at the half-power points of the beam. If frequency-switching these are at HPN, HPS, HPE, HPW, ON, ON. If position-switching these are at HPN, HPS, HPE, HPW, ON, OFF. Total duration is 6 x SPTIME. The half-power beamwidth is automatically obtained from SYPARM. it can be approximately computed from the observing frequency, knowing the size of the telescope (HPBW/deg = 67 * wavelength [ metres ] / diameter [ metres ]).
Mandatory for pulsars. The pulsar period in seconds.
Mandatory for pulsars. The pulsar period derivative in s/s^1. Also known as "pdot".
Mandatory for pulsars. The pulsar period second derivative in s/s^2 Also known as "pdotdot".
Mandatory for pulsars. The dispersion measure in units of pc/cm^3. Needed for glitch checking (?)
Mandatory for pulsars. The rate of change of the dispersion measure with time in units of pc/cm^3/s^1 (?) Needed for glitch checking (?)
Mandatory for pulsars. The epoch in Julian days applicable to PLPERIOD, PLPDRV1, PLPDRV2, PLDM and PLDMDRV.
Optional for pulsars. Parameter is a numerical factor to do with polarization, does what? If PLPOL is omitted, the default value is unity.
Mandatory for pulsars. The phase offset from current ephemeris at the time of the most recent observation, in milliperiods, also known as the "drift". When glitch detection is on, this is updated in this or another disk file by the observing program. The concept of doing this must be considered - do we want observing programs modifying their own source files? A separate file dedicated to maintaining the latest phase seems a safer idea. Is it frequency-dependent?
Mandatory for pulsars. The time constant to be set for the post-detection filter, in microseconds.
Mandatory for pulsars. The number of periods to integrate at each frequency band. An implication of this is that it must accompany a frequency definition as a second parameter. PLPINT x PLPERIOD defines the scan time, needed for the scheduler.
Optional for pulsars. Defines the glitch detection status. If the keyword is not present, glitch detection is OFF. The parameters are:
Optional for pulsars. Defines whether to calibrate using the noise diode or not. If the keyword is not present, its status is ON. The parameters are:
Optional for holography (int). Single parameter is the total number of scans in the map. It is defaulted to 16 if not specified (large enough to resolve the main beam). It is recommended that the map is sized at least above 64 points, 100 is typical. Map size determines the mapped resolution R = Dish_diameter/(over_sampling_factor*HORSSZ).
Optional for holography (double). Single parameter is the angular space between the scans. Units in degrees. It is defaulted to 0.0424 degrees for an over sampling factor of 0.75. It is recommended that the map is oversampled at a factor between 0.7 and 0.8. The nyquist spacing in radians nq = wavelength/Dish_diameter, multiply nq by the desired factor to calculate (remember to convert to degrees).
Optional for holography (int). Single parameter to determine at which scan the map must begin, used for continuing interupted maps. Default value set to 1.
Optional for holography (int). Single parameter for the number of correlator channels used. Allowable values are: 256, 512 and 1024. Defaulted to 1024 channels. It is recommended that the whole correlator band is used to dilute the strong CW signal. The number of channels could be lowered if correlator files were generated to match. The corresponding correlator bandwidth is set by the standard BANDWDTH keyword.
Optional for holography (int). Single parameter is the integration time used, defaulted to 5 seconds. Recommended value of minimium of 3 seconds, for noisy maps it might be required to integrate longer. Integration times of longer than 10 seconds do not, typically, improve the noise.
Optional for holography (int). Single parameter at which scan to stop at. Used for breaking up a large map. Default value is HORSSZ, i.e does the whole map.
Optional for holography (int). Single parameter for the number of boresites done before and after the scan data is recorded. Defaulted to 3. Should be set to a minimium of 3 or longer depending on the measured noise.
Optional for holography (int). Single parameter for the number of scans to peform in a row between boresite readings. Default value is 3. Must be sized so that the boresite drift is resolvable.
Optional for holography (double). Single parameter for the over sampling factor to sample the map in the scanning direction. The default value is 1.2, to obtain a square grid this can be set to 1. It is, however, recommended that the raster is slightly oversampled in the scanning direction. Adding extra points in this way is more time efficient than spacing the scans closer.
NOTE: The beacon frequency is specified using the standard RESTFREQ keyword.
A catalogue must not contain scheduling-specific keywords.
A catalogue must at minimum define:
All observation types require source coordinates:
For calibrator sources, coefficients defining the flux density are optional:
For spectra, the catalogue can optionally contain:
Example:
Object G188.95+0.89 comment can do pointing at 6668 coordsys equatorial equinox B1950 ra 6 5 53.5 Dec 21 39 2.0 spvlsr 10
For pulsars, the catalogue also contains ephemeris information:
For example:
Object PSR 0740-28 coordsys equatorial ra 7h 40m 47.8494s dec -28d 15m 32.9291s equinox B1950 plperiod 0.166763687712 plpdrv1 0.1683063E-13 plpdrv2 0.00 pldm 72.73 pldmdrv 0.00 plepoch 50286.35546