THE SCHED USER MANUAL
Version 11.6, Released May 2020

R.C. Walker

May 22, 2020

This release, 11.6 (May 2020), is a data-only update to the earlier 11.5 (Septemper 2018) release. The versions reported by the executables was the only update to the software itself.

SCHED is a program for planning and scheduling Very Long Baseline Array (VLBA), High Sensitivity Array (HSA), Global Very Long Baseline Interferometry (Global VLBI), European VLBI Network (EVN), Long Baseline Array (LBA; Australia), Korean VLBI Network (KVN), VLBI on the Karl G. Jansky Very Large Array (VLA) and other VLBI observations. It writes VEX files that describe the details of an observation and are becoming the near universal format for distribution of schedules to VLBI telescopes and correlators.

This manual describes how to use the program, provides extensive information on all possible inputs, and gives considerable information and advice on many aspects of scheduling VLBI observations. The INTRODUCTION gives an overview of the program and is the only chapter that a new user should read before starting to use the program. The rest of the manual can be treated as a reference to be consulted to answer questions.

Scheduling with SCHED involves creating an input file with a text editor, and then running the program on that file. SCHED creates a variety of output files that provide summary and detailed information to the scheduler and telescope control information for the VLBI station. The easiest way to create an input file is to copy one of the examples and modify it for your particular project. All of the examples are complete, working files. SCHED is not interactive unless plots are being made, in which case there is a convenient, interactive interface to control the plotting. The plotting capabilities should be very useful, especially during proposal writing and while planning observations.

This edition of the manual corresponds to the SCHED version as indicated in the title. Please be sure that you have the latest major version of the code and catalogs to be sure your schedule files are valid. Please check the notes on the current release to be sure that you don’t need a more recent minor release than the one you have (these are usually bug fixes). The distribution files for the latest releases are available on anonymous ftp at ftp.aoc.nrao.edu in directory pub/sched.

In several places in this manual, there are links to text files that come with the manual. Some browsers just display those files without issue. But, since the files typically don’t have a .txt extension, sometimes the browser won’t display them natively and won’t give an option to do so. I encountered this with Firefox on a Mac. It thinks the .key files are Keynote files. I found an add-on called “open in Browser” that deals with the situation. You can find it with a search.

For general, and NRAO specific, comments and questions, please contact the help desk (helpdesk@nrao.edu) or Amy Mioduszewski. For EVN, Mark IV and non-VLBA VEX format issues, contact Des Small at small@jive.nl. SCHED was written by Craig Walker of NRAO with significant contributions from Huib van Langevelde, Cormac Reynolds, Antonios Polatidis, Friso Olnon, and Des Small of JIVE, and Franco Tinarelli of CNR in Bologna. Craig Walker retired at the end of 2014 and Amy Mioduszewski is now the main NRAO based SCHED supporter. Des Small and Cormac Reynolds are the main active non-NRAO supporters. Craig will continue a low level of involvement but should not be the first person to contact with issues. The manual is long and has been supported mainly by one person, so, in this period of rapid changes in hardware, please excuse occasional sections that are not entirely up to date.

Contents

 0.1 Important Notes - Please check these
 0.2 Links to Manual Sections and to External Information.
1 INTRODUCTION
 1.1 Overview
 1.2 Keyin Free-format Input
 1.3 SCHED Input and Output Files
 1.4 Examples
  1.4.1 A Basic VLBA Schedule.
  1.4.2 A Minimal Schedule for Planning.
 1.5 Plotting
  1.5.1 Keyin Input for Plotting (obsolete)
2 INFORMATION AND ADVICE ON SPECIFIC TOPICS
 2.1 Using SCHED for Project Planning
 2.2 Scheduling Tips
  2.2.1 Observing Strategy
  2.2.2 Scan Times
  2.2.3 Dynamic Scheduling
  2.2.4 Management of Data Recordings
 2.3 Recording Systems.
  2.3.1 Recording Systems History and Background
  2.3.2 Recording Systems Control
  2.3.3 MARK5 and EVLBI
  2.3.4 VLBA
  2.3.5 MARK IV (PCFS)
  2.3.6 NON–VLBA Telescopes with VLBA Recorders
 2.4 Wide Band Observing: RDBE, DBBC, VLBA and Mark IV Modes
  2.4.1 The RDBE system
  2.4.2 DBBC:
  2.4.3 OTHER DIGITAL BACKENDS:
 2.5 Spectral Line Observations
 2.6 Reference Pointing
 2.7 Multiple Phase Centers
 2.8 Automatic Insertion of Geodetic Segments
 2.9 Scheduling the VLA
 2.10 Special Concerns for Specific Observatories
  2.10.1 Green Bank Telescope.
 2.11 Single Dish VLBA Observing
 2.12 Configuration Studies
 2.13 Satellite Tracking
3 THE SCHED INPUT FILES (Includes parameter lists)
 3.1 The Schedule File
  3.1.1 Summary List of SCHED Parameters
  3.1.2 Details of SCHED Parameters
 3.2 Source Catalog
 3.3 Station Catalog and Locations Catalog
 3.4 Tape Initialization File
  3.4.1 Details of Tape Initialization Parameters
 3.5 Frequency Catalog
  3.5.1 List of Frequency File Parameters
 3.6 Setup Files
  3.6.1 Standard Setup Files
  3.6.2 Examples of Setup Files
  3.6.3 Summary List of Setup File Parameters
  3.6.4 Details of Setup File Parameters
 3.7 Satellite Initialization.
4 INSTALLING, AND RUNNING SCHED
 4.1 Installing SCHED
 4.2 Running SCHED
  4.2.1 Running SCHED under UNIX or LINUX
  4.2.2 Running SCHED on a VAX with VMS
 4.3 Distribution of Schedule Files
 4.4 Related Programs
 4.5 Release Instructions.
5 RELEASE NOTES
 5.1 Recent Releases
  5.1.1 Version 11.6 development
  5.1.2 Version 11.5 (released September 2018)
  5.1.3 Version 11.4
  5.1.4 Version 11.3
  5.1.5 Version 11.2
  5.1.6 Version 11.0
  5.1.7 Version 10.2
 5.2 Old Releases
  5.2.1 Version 10.1
  5.2.2 Version 10.0
  5.2.3 Version 9.4
  5.2.4 Version 9.3
  5.2.5 Version 9.2
  5.2.6 Version 9.0
  5.2.7 Version 8.1
  5.2.8 Version 8.0
  5.2.9 Version 6.05
  5.2.10 Version 6.04
  5.2.11 Version 6.02 (Released 29 July 2005)
  5.2.12 Version 6.01
  5.2.13 Version 6.0 - Released March 8, 2005
  5.2.14 Release of 18 September 2003.
  5.2.15 Release of 02 July 2002.
  5.2.16 Release of 16 October 2001.
  5.2.17 Release of 12 February 2001.
  5.2.18 Release of 30 January 2001.
  5.2.19 Release of 12 January 2001.
  5.2.20 Release of 28 April 2000.
  5.2.21 Release of 1 July 1999.
  5.2.22 Release of 1 Dec. 1998.
  5.2.23 Release of 30 March 1998.
  5.2.24 Release of 18 Nov. 1997.
  5.2.25 Release of 18 August 1997.
  5.2.26 Release of 1 Aug. 1997
  5.2.27 Release of 10 Feb. 1997
  5.2.28 Release of 14 Jan. 1997
  5.2.29 Release of 4 Dec. 1996
  5.2.30 Release of 26 June 1996
  5.2.31 Release of 13 Apr 1996
  5.2.32 Release of 22 Feb 1996
  5.2.33 Release of 16 May 1995
 5.3 Wish List
A APPENDICES
 A.1 Station Codes
 A.2 Historical Notes
B OBSOLETE SECTIONS
 B.1 Old VLA
  B.1.1 VLBI at the VLA - old system
  B.1.2 VLA-Only Project Example
  B.1.3 Parameters Specific to the VLA
  B.1.4 VLA Standard Bands.
 B.2 Tape Management
  B.2.1 GENERAL CONCERNS
  B.2.2 TAPE HANDLING at SCAN BOUNDARIES
  B.2.3 TAPE LENGTHS and PASS TIMES
  B.2.4 NUMBER of PASSES
  B.2.5 READBACK TESTS
  B.2.6 TAPE CHANGES
  B.2.7 POSTPASSES
  B.2.8 AUTOMATIC TAPE ALLOCATION
 B.3 Mark III Observations
 B.4 Scheduling Mark II Observations
 B.5 Head Positions and Track Assignments
 B.6 S2
 B.7 Green Bank 140’.
 B.8 Installation on Mac OSX 10.3 in 2003.

0.1 Important Notes - Please check these

The world of VLBI has mostly converted from the traditional backends to the newer digital backends such as the RDBE and the DBBC and to newer recording systems such as the MARK5C. SCHED supports many of the digital backends and new recorders. You may encounter some legacy information in the manual and examples that relate to the old systems.

The MARK5A recorders were removed from the VLBA in December 2013. All projects must now use the RDBE. All VLBA stations have two RDBE units for a total of 8 channels with the DDC. Most MARK5A setups can be duplicated with this system. Most of the standard setups with names like v6cm... will work with the DDC. As of April, 2014, half of the BBCs in the legacy system will be unplugged. The remaining ones are still used to collect pointing data and some old style calibration data, mainly for test purposes.

Mark IV users please see the Mark IV Section for information about mode and mode change restrictions.

If you are using B1950 coordinates, you should worry about the “observe” date to use for precession. Please see the discussion of the input parameter PRECDATE. But you really should not be using B1950 coordinates!

Please note that all setup files intended to be used for spectral line observations using DOPPLER must have all channels distinguished, in the setup file, by frequency and polarization. In the past, it was common practice to set all channels to the same frequency, and let the Doppler calculations separate them. But the requirement to deal reasonably with single polarization sites in dual polarization observations forced SCHED to be able to relate channels from each station to channels from other stations within the setup file. This is mentioned here because it has proven to be the source of considerable confusion.

Try the plot capability (UV, El vs time etc). It’s easy to use and should help with planning and with understanding what your schedule will provide. See the plotting section for details.

This manual is written with LaTeX and converted to html using htlatex. It is meant to be read using a browser. A postscript or pdf version could be generated for printing. But it is over 300 pages long and should be updated with each release. Printing it would be considered unfriendly to the world’s forests. The authors have not printed it in many years.

0.2 Links to Manual Sections and to External Information.

New users — please read:

Introduction: General information about SCHED.

Keyin Free-Format Input: The data input format common to all files.

Input and Output Files: Brief descriptions of SCHED’s files.

Running SCHED: How to get it to execute.

Getting started: Some examples which can be used as templates.

Observing strategy: Some tips.

Installing SCHED: If SCHED is not yet on your computer.

The SCHED input files and their input parameters:

The main input schedule.

The Station Catalog.

The Source Catalog.

The Setup Files.

The Frequency Catalog.

The Tape Initialization File.

Spectral Line Frequencies.

Different types of VLBI observations:

VLBA observing: Most of this manual.

VLA observing for VLBI.

General information on non-VLBA systems.

Mark IV (and VLBA4) VLBI observing.

Non-VLBA telescopes with VLBA recorders.

S2 VLBI observing. Obsolete.

VLBA Single-Dish observing (mostly test observations).

Detailed advice and information:

Project Planning: How to use SCHED while writing proposals and while designing an observation.

Making plots: UV coverage, elevation vs time etc.

Scan times: The many ways to specify when to observe.

Tape management: Obsolete since the advent of disk recordings.

Head positions and track assignments: Some gory details for the masochistic.

Special concerns for specific observartories.

Distribution of SCHED files: Where to send the output files.

Related programs: Where does SCHED fit in.

Station codes: A list, a bit dated.

Changes to SCHED: A list of recent SCHED changes.

A history of SCHED: A brief history.

Some links to other sources of information:

NRAO Home Page: General information on NRAO and links to most NRAO resources.

VLBA Home Page: VLBA information and links including much of importance to someone scheduling VLBI.

VLBI at the VLA. Extensive information on VLBI observations with the VLA.

VLBI on the GBT: Information about using the GBT for VLBI. Please consult this if you are using the GBT. There are special concerns, such as temperature dependent slew rates and many others, that can significantly affect scheduling.

VLBI at Arecibo: Information about VLBI at Arecibo. You will need to follow a couple of links from the above page - somehow the URL doesn’t change going down the links.

JIVE Home Page: A good place to start for information on European and Global VLBI.

Chapter 1
INTRODUCTION

1.1 Overview

SCHED is a program for scheduling Very Long Baseline Interferometer (VLBI) Observations. It can be used to schedule any observations on antennas that use the VLBA real time control software and to schedule Mark IV/VLBA(4)/S2/Mark5 observations on any stations that can read VEX format schedules. SCHED is the program used to schedule essentially all non-geodetic VLBA projects and has been adopted by the European VLBI Network (EVN) as the standard scheduling program for the EVN. SCHED is also a useful tool for planning observations, both at proposal writing time and before making detailed schedules. The plotting capabilities are especially useful for this.

To use SCHED, one normally creates an input file, using any text editor, that describes the schedule. Then SCHED is run on that file. A number of examples are distributed with SCHED. The usual and recommended way to make a schedule is to copy one of the examples and modify it according to your specific needs. When developing a schedule, it is likely that SCHED will be run several times before everything is to the scheduler’s satisfaction. The various output files, especially the summary file and the optional plots, provide a lot of information about the schedule that can be used to help the user with optimization.

SCHED gets a lot of information, including station locations and equipment, source positions, and frequency setups, from a number of catalogs. Most catalogs can be imbedded in the schedule, but it is much more common to use the standard ones provided with the SCHED distribution. An effort has been made to put as much information as possible in the catalogs so that the user only need provide very generic information specific to the particular project. But if the user wants to do something special, it is possible to specify the parameters of an observation in great detail. Documenting all these capabilities partially explains the large size of this manual, most of which is not needed by the average user.

SCHED writes several different types of output files, some of which are useful for the scheduler and some of which are meant for the computers at the antennas. An outline of the files used by SCHED can be found in the section on files. The summary file is the most important one for the user. It gives the details of the equipment setups at each station and a summary of various items about the individual scans.

The beginning user might start by looking at one or more of the example files to get a sense of what they look like. Then read some of the sections that cover important details, without which it might be difficult to understand what is going on. The section on KEYIN Free Format Input covers the capabilities and limitations of the parser used to read all input files. The section on Inpuut and Output files gives an overview of the information that SCHED requires. The Running SCHED section has instructions on how to start the program. And the Examples section contains 2 examples of SCHED input files and quick descriptions of, and links to, most of the rest provided with the distribution.

After reading the sections recommended above, it would probably be best to use one of the examples to experiment with the program. The examples are complete, working files. In fact, they are all used regularly to test SCHED modifications. They will work as is, and it can be modified to try other features. The easiest way to make a schedule for your project will usually be to select the example that is closest to what you are trying to do and modify it to your needs. It is not strictly necessary to read the rest of the manual. It can be treated as a reference to help answer questions.

The files needed to run SCHED are in various subdirectories under the base directory used for the SCHED installation. That base directory, on unix systems, should be assigned by you or your system administrators to the environment variable SCHED. The key subdirectories are examples, setups, catalogs, doc, src, and bin and can be referred to, on unix systems, using paths such as $SCHED/catalogs. For most the contents are obvious from the names. src contains the code and bin contains the executables, perhaps in architecture dependent subdirectories. The user should work in a private directory and only refer to files in the SCHED standard areas, not modify them. All SCHED output files are written in the current working directory.

There is a lot of information about SCHED and about the process of scheduling VLBI observations in the descriptions of the input parameters and of the parameters for the setup files. There are detailed discussions of some specific areas of concern in the Scheduling Tips Section . This section will be expanded significantly in the future. All of these sections are worth reading through on some slow day for those serious about scheduling.

VLBI projects can also be produced using the NASA Goddard program SKED and VLBA control files can be produced using DRUDG. That is the standard path used by the geodesy community, but is rare among astronomers.

SCHED may be obtained by anonymous ftp from ftp.aoc.nrao.edu under directory pub/sched. For more information, see the section on Installing SCHED. Users are encouraged to obtained the current release of SCHED before attempting to make schedules. The program is continually evolving to support new features and to make it harder to write schedules that won’t work. It is in your own best interests to have the current version. For most users, installing a new version should involve little more than copying and unpacking the tar files and copying the executable for their type of machine.

A note on notation: the names of computer programs will be given in SMALL CAPS font, the names of files will appear in slant font, and the names of SCHED and setup file parameters will appear in typewriter font. Some parameters may be abbreviated; where both compulsory and optional characters are displayed, the compulsory ones will be shown in UPPER-CASE TYPEWRITER font and the optional ones shown in lower-case typewriter font.

1.2 Keyin Free-format Input

All input parameters to SCHED are in the keyin free format, named after Tim Pearson’s subroutine that is used to read it. The important features of that format for SCHED are described here. This description is not complete and users of the Caltech package should refer to other documentation for useful capabilities of keyin input that are not normally used for SCHED.

Input via keyin format is of the form keyword = value. Different sets of keywords and values are separated by spaces or line breaks. The equal sign is optional as long as its absence does not lead to ambiguity. The input keywords are not case sensitive. Most of the values required by SCHED, except for file names in case sensitive systems like unix, are also not case sensitive. keywords are, in all cases, limited to 8 characters in length. Character string values can be much longer.

A few SCHED keywords may be abbreviated. In the parameter descriptions in this manual, the required characters will be shown in upper case while the optional ones will be shown in lower case. Any characters beyond the required ones must match the optional ones. As an example, the keyword DURation can be typed as DUR, dur, DURATION, duration, durat, Dur .....

A value can be an array, with elements of the array separated by commas. If the last character on a line is a comma, the input array is assumed to continue on the next line.

The value can be a number or a character string. Quotation marks are required for a character string if it can be mistaken for a number or if it contains blanks or commas. Also, because of possible ambiguity with other keywords, character string values must be in quotes if the equal sign is left out.

If the value is a number, the decimal point and fractional part are optional. The parser converts all numbers to double precision real so the program will not know if you specify “5” or “5.0” etc. The value can be an arithmetic expression enclosed in parentheses. An example would be (5.5*4). The expression cannot contain blanks or the parser will get confused.

If value is a time or angle, it can be written in hh:mm:ss.ss or dd:mm:ss.ss format. Each colon causes all values to the left to be multiplied by 60, giving a result to the program that is in seconds. Values less than an hour or degree can be written mm:ss.ss or just ss.ss. The decimal and fractional seconds are optional. However, even hours or degrees require the colons; for example, 2 degrees is written as 2:0:0. Numbers larger then 60 are allowed for the minutes and seconds; for example, 2:40 and 160 are equivalent. No imbedded blanks or signs are allowed. A negative or positive sign is allowed in front and applies to the final total number of seconds (i.e., -1:20 is returned as -80).

A keyword can be specified without a value. This is equivalent, as far as the program knows, to specifying a value of zero. Some keywords are used in this way as logical switches to cause something to happen. DOVEX, DOPPLER, and PTVLBA are examples from SCHED. Usually the effect of such a switch can be reversed by specifying a non-zero value. For several such switches, SCHED has a corresponding variable keyword that has the opposite effect (for example: RECord and NORECord).

An exclamation mark (“!”) causes all items on the rest of the line to be ignored. This is useful for adding comments.

The parser collects all input, regardless of how many lines it is on, up to the line on which it finds the “Endmark”, which in the case of SCHED and most other programs is a “/” . For SCHED, these groups correspond to scans in the main input, or a station or a source in the main catalogs.

Some examples of valid, if not very consistent, SCHED input are:

  SOURCE=’0235+164’  YEar = 1988  day 67  Stat = ’OVRO’,NRAO,  
   vla,vlba_pt  stop 03:35:00  dur = 15:00  
  comment ’Quotes are needed for more than one word.’  /

When a program that uses keyin is run interactively, the user can obtain a list of inputs by typing “HELP /” and can obtain a list of the current values of all input variables by typing “SHOW /”. The input of SCHED is rarely, if ever, given interactively.

Keyin values can be mathematical statements in parenthesis; for example,

  dur = 15  
  rep = (4*5)

This example shows the most likely way in which this capability might be used in SCHED input files. These two commands mean that the scan, which is 15 seconds long, should be repeated 20 times. By using the (4*5), it makes it clear that the repetition lasts for 5 minutes since there are 4 scans per minute.

1.3 SCHED Input and Output Files

SCHED takes input from several types of files in addition to any interactive input. All of these files can be separate, as long as SCHED can find them, or most of them can be imbedded in the main input file. The former is more convenient. But, when the input file is to be sent somewhere else to be run again, it may be safer to imbed the catalog information in the main file. All input to SCHED is in the keyin free format section. This is the same format as is used by all Caltech VLBI package programs. The input file types are:

Main Schedule Input File:
This is the file that contains the details of the particular project. It can have the most of the other files imbedded in it. This file must be created by the user. This file should be given a name like bv016.key for project BV016. See the /schedb examples for numerous samples.
Source Catalog:
These files contain the information about the sources, especially names, positions, and, for line sources, velocities. There are standard source catalogs, although the user may need to add non-standard sources. Source catalog entries can be included in the Main Schedule Input File. There are two standard source catalogs which are $SCHED/catalogs/sources.gsfc, and $SCHED/catalogs/sources.petrov, which contains sources respectively from from the Goddard geodesy group and from Leonid Petrov. The links above are actually to symbolic links to the latest catalog from each source as of the time of the SCHED release. These catalogs contain thousands of sources (near 10,000 in Petrov’s case), so the old catalog that contained a few sources from elsewhere has been abandoned. Two external catalogs can be specified if one wishes, for example, to use the standard one for calibrators and another for multiple phase centers.

Please note that this source catalog, along with the locations catalog, is updated approximately annually. It cannot be relied upon to maintain constant positions for a multi-year project. If you need constant positions, include your own set in your schedule. Otherwise, include a step in processing that accounts for changes in the assumed calibrator position. Note that the Earth orientation and station locations actually change with time (plate tectonics etc) so exact repeats of the observing geometry are not possible.

Station Catalog:
This file contains information about the antennas including names, positions, slew limits, horizons etc. There is a standard station catalog that should suffice for nearly all users. If not, entries can be included in the Main Schedule Input File. Station positions may stored separately in the Location Catalog. The standard station catalog is $SCHED/catalogs/stations_RDBE.dat. The old version for use with the legacy VLBA systems is still $SCHED/catalogs/stations.dat. By the next SCHED release, it is likely that stations.dat will be the RDBE version and the legacy version will be renamed or removed.
Location Catalog:
This file contains station locations. The standard version reflects the locations and velocities used on the VLBA correlator. It is documented along with the Station Catalog because they are tightly coupled. The Locations Catalog is optional since it is not needed if the station locations are specified in the Station Catalog. It exists separately for ease of maintenance. The standard location catalog is $SCHED/catalogs/locations.dat.
Setup Files:
These files contain the details required to configure the hardware at the stations. Different projects using the same hardware configuration can use the same setup files. There are many standard setup files are located in $SCHED/setups.
Frequency Catalog:
This file contains information about valid frequency setups at the stations. The RF ranges that can be covered and the local oscillator and polarization of each IF are given. SCHED can use this information to provide good defaults for many parameters in the setup files. The standard file should be used. Any non-standard information can be in the setup files. This file cannot be imbedded in the main input file. The standard frequency catalog, for use with the RDBE systems, is $SCHED/catalogs/freq_RDBE.dat. The legacy version is still available. It is $SCHED/catalogs/freq.dat The main difference is that the VLBA IFs are assumed to be between 512 and 1024 MHz in the RDBE version, not 500 and 1000 MHz as in the legacy version. By the next SCHED release, the RDBE version will likely become $SCHED/catalogs/freq.dat and the legacy version will be renamed or removed.
Tape Initialization File:
This file tells SCHED the properties of the tape systems at the stations and where to start on each tape. Since tapes are no longer in use, this file is mostly obsolete. However it can be used to specify use of a recording system at a station that is different from what is given as the default in the station catalog. This is generally only useful during periods when stations are transitioning between different recording systems. Note that many old files, often used as templates, contain tape initialization sections. These should be removed.
Reference Pointing Control File:
SCHED can insert scans for reference pointing at high frequencies on the VLBA and VLA. This file contains information needed to control that function. It will only be of interest for observations above 15 GHz on the VLA and at 86 GHz on the VLBA. The standard reference pointing control file is at $SCHED/catalogs/peak.cmd There is a special version related to reference pointing when using the new wideband (RDBE/MARK5C) system on the VLBA. It is $SCHED/catalogs/peak_RDBE.cmd.
Spectral Line Rest Frequencies:
SCHED can adjust the observing frequency to remove the Doppler shifts due to the motions of the Earth around the Sun and to the Sun with respect to a desired reference frame. To do this, SCHED needs to know the rest frequency of the line being observed. This is given in a lineinit section imbedded either in the main file or in the reference pointing control file. There is a file, $SCHED/catalogs/linefreqs.dat, distributed with SCHED, that gives the rest frequencies for many of the maser lines commonly observed with VLBI.
Ephemeris file:
SCHED can be used to schedule observations of planets. To do so, it obtains positions from a JPL ephemeris file. Mostly this is used for single-dish calibration observations.
Satellite file:
SCHED can also be used to schedule observations of satellites. To do so, it obtains orbital elements from the SATFILE or TLEFILE which are specified in the SATINIT section. This is used for holography and for spacecraft navigation projects. Satellite tracking is discussed in the Satellite tracking section

SCHED processes the input files and creates several output files. Most follow a naming convention that starts with the project code (bv016 will be used in the examples here) followed by a file type indicator, then a period, then a two letter station code (pt for Pie Town in the examples below). The experiment code is read by SCHED in the EXPCODE parameter in the main schedule input. The station code comes from the station catalog and a list if given in Appendix A.1. The output files are:

Summary File:
This file gives a rather extensive summary of the setups and observations. This is the most useful output file for the user as it shows how SCHED has interpreted the input commands. The file will be called, for example, bv016.sum. The items displayed for each scan can be controlled with the parameter SUMITEM.
sched.runlog:
This file reflects most of what you see on the screen when SCHED is running, plus may contain additional messages that help debug problems should they occur.
Operator Schedule Files:
These files, of which there is one per antenna, give much more information about the schedule than can be included in the summary file and are useful when that level of detail is needed. They were originally meant for the use of operators of manually controlled antennas, but now most antennas are computer controlled and these files are more useful for the scheduler. The files are named, for example, bv016sch.pt.
VLBA type Antenna Control Files (crd files):
These files provide the legacy on-line control systems of the type found at VLBA antennas with the information they need to control the observations. There is one file per antenna that uses a VLBA control computer for either full control of the station or for control of just the data acquisition system (data recorders, baseband converters etc.). The files are named, for example, bv016crd.pt. Note that the VLBA antennas currently are in transition with some items controlled by the legacy system and some by the new control system which is commanded using the VEX file.
VEX file:
This is the main output file needed by the stations for antenna and recording system control and by the correlators to process observations. It is now used by most VLBI systems around the world, not just the Goddard “Field System”. For the VLBA, it is used to control the RDBE, MARK5C, and some antenna data path switches. The legacy system, commanded by the crd files described above, still controls the antenna pointing among various functions. Both are needed. A single VEX file describes the observations for all antennas.
V2D file:
This is a template correlator setup file for the (VLBA) DiFX correlator. Information that needs to be modified from what is in the VEX file can be specified by the analysts in this file. It is also the path to transmit information about multiple phase centers per pointing to the correlator.
Flag file:
SCHED writes a file with the .flag extension that can be helpful in data processing. It contains flag entries, in the format appropriate for the AIPS task UVFLG, that cover the times when data are being recorded, but the antenna is expected to be slewing. For the VLBA, the monitor flags would usually take care of such times, but for other types of stations, such information is not always available from the logs.
Preempt file:
Starting in Oct. 2011, the VLBA will be providing observations of up to 1.5 hours on the Pie Town to Mauna Kea baseline to the USNO for EOP determination. This is in return for financial support for operations. These observations will preempt the scheduled project on the two stations. There is some flexibility to choose the exact time of the preemption so the user has been given some ability to guide the choice. Important scans can be protected using the PREEMPT parameter. Information in the preempt file, which is also in the summary file, is used by operations when picking the time for the EOP observations.
Plots:
Sched can make plots of u-v coverage and of various combinations of azimuth, elevation, paralactic angle, hour angle, UT, and GST against each other. Plots can be made of the time antennas are up. Plots can be made of beams. The plot capability can be used to plot the distribution of your sources, and of the all sources in the catalog, on the sky. This is useful for looking for calibrators. In advanced modes, stations can be moved around to explore UV coverages in array configuration design projects. Also quality factors can be calculated and plotted with contours over a map of the stations. There is interactive control over the plotting, the only interactive part of SCHED. Much of this capability is mainly useful in experiment planning.
DiFX configuration file:
When making jobs for the DiFX correlator, especially as used for the VLBA, a .v2d file is used to give information not readily deduced from the .vex file. SCHED now writes a template for that file. That file is also be used to pass lists of phase centers when utilizing the DiFX multiple phase center capability.
Optimized Schedule:
When one of SCHED’s optimization modes is turned on, or geodetic segments are requested, the program writes out a file, such as bv016.sch containing the basic scan inputs for a new main schedule file. If desired, the user can use this to construct, and perhaps modify, a new optimized main schedule input. This used to be the way all optimized schedules were constructed, but now that SCHED fully processes an optimized schedule, it is rarely used or needed. The newer use is to make it easy to reproduce geodetic segments when something else is changed that would otherwise change the results of the optimization.
frequencies.list:
If the user specifies the parameter FREQLIST, SCHED will read the frequency catalog and make a table of all known setups which can be used to make observations in the specified frequency range. Then SCHED will quit without doing further processing. This is useful for planning and for information while making setup files.

1.4 Examples

There are a number of example SCHED input files distributed with the program. They are in the examples subdirectory ($SCHED/examples if the environment variable is set on unix systems). Any can be consulted for information on how to run SCHED or for use as templates from which to create your own schedule. All should produce valid schedules if run as is. In fact, all are used in the Verify script that is used to check new installations and new versions of SCHED. All of the examples are described briefly and linked here. As of Dec. 2013, there were 52 examples. Some consolidation is on the agenda for future releases, partly from purging ones most appropriate for the legacy systems no longer in use.

The two examples in subsections below show a typical, reasonably simple, schedule and a minimal schedule of the type one might use for experiment planning. The latter is likely to be useful when writing proposals or doing other conceptual work.

Note that the example suite has grown up over many years and is in some considerable need up updating. All are valid schedules that run and could be used. But many features used are dated and new features and currently preferred styles are still only seen in a few. Some with recent (After late 2010) modifications that are especially current are manual_1.key, egdelzn.key, egrdbe.key, egrdbe2.key, egddc.key, and egcent.key which target certain new features, but also show decent scheduling style.

See the section of this manual on installation if SCHED is not yet installed on your computer and if your login is not set up to run SCHED. Also see the Running SCHED section for instructions on how to start the program.

If your version of SCHED is linked with the PGPLOT libraries (has plotting capability) and you are on a unix system, you will need to set the environment variables PGPLOT_DIR to the location of the PGPLOT libraries and PGPLOT_FONT to the location of the PGPLOT font files, if that is not the same as PGPLOT_DIR.

manual_2.key
This file is shown below as the first example. It is a fairly typical SCHED input file for a VLBA plus the GBT observation. It uses defaults where it can and is relatively simple. This example is a good file to use as a template for making new schedules. This file has not been updated from MARK5A to MARK5C.
manual_1.key
This file will produce the same schedule as the first example. However, for demonstration purposes, far more parameters are actually specified in the input file. This includes having at least parts of all auxiliary input files (catalogs etc) imbedded. It is fairly complicated and contains a lot of comments in an attempt to show many SCHED features and give some advice on scheduling strategy. It has been updated to use the RDBE/DDC system on the VLBA and the WIDAR on the VLA.
manual_simp.key
is the second example below. It is a very simple file that can be used to make plots for experiment planning purposes. Because of the lack of cover information and because of the special optimization mode used, it cannot be used to produce telescope control files.
egplan.key
is much like [manual_simp.key]. It is a simple schedule to assist in experiment planning. It is a bit more complete than manual_simp.key.
eglst.key
is a sample schedule using LST in the way requested for dynamic scheduling projects on the VLBA.
egvlba.key
is a sample schedule for VLBA observations. It demonstrates band switching and some recording control procedures not in manual_2.key. It also demonstrates providing PREEMPT=EXTRA scans on the ends of the project so that operations might be able to provide extra data if there is a gap that cannot otherwise be filled between projects.
eg24.key
is a sample schedule of a simple project on the VLBA, but one that goes for 24 hours. For dynamic scheduling, it is useful to be able to wrap such schedules to use a different start time. This shows how to put in comments for the schedulers to aid that process and shows how the schedulers can use parameters WRAP24 and DOSCANS to simplify the wrapping process. Note, this has not yet been updated from MARK5A to MARK5C.
egOH.key
is a sample spectral line file for VLBA observations of several OH masers transitions.
egcent.key
is a sample showing how to specify multiple phase centers for a pointing center for the DiFX correlator.
egdelzn.key
demonstrates how to use the capability in SCHED to add automatically short geodetic segments for the purpose of atmospheric calibration delay. Note that similar segments, with very short scans, can be added for tropospheric opacity calibration. This example also shows the use of the PREEMPT parameter to protect specific scans from preemption at Pie Town and Mauna Kea for daily EOP observations of up to 1.5 hr.
dqhiel.key
demonstrates how to use the HIGHEL optimization mode which can pick the scan with the highest elevations across the array from among a group of suggested scans. It is useful for testing but also can be useful for picking fringe finders etc. This schedule is based on the regular data quality tests.
egrdbe2.key
demonstrates a SCHED file for use with the new digital backend and Mark5C recorders being deployed on the VLBA and elsewhere. This one is relatively simple and uses the PFB personality which gives many channels of fixed frequency and bandwidth. It does exercise the mode where one station (GBT) has to observe in the opposite sideband from others.
rdbepfb.key
is a stripped down version of egrdbe2.key that shows a rather basic schedule for the VLBA only using the RDBE with the PFB personality. It uses a SCHED standard setup so the user doesn’t need to set the configuration information.
egcwide.key
Example sched input for a VLBA using the RDBE with the PFB personality and the wideband 6 cm receiver. Setups are given that use dual polarization in one pair of IFs and that use single polarization in two IFs at very different frequencies.
egddc.key
demonstrates a SCHED file for use with the new digital backend and Mark5C recorders being deployed on the VLBA and elsewhere. This one allows flexible baseband frequencies and bandwidths, but provides fewer channels than the PFB personality.
egddc2.key
demonstrates a SCHED file for use with 2 RDBE’s and 8 channels from the DDC personality. Otherwise it is a fairly simple VLBA schedule. The deployment of 2 RDBE’s is expected in early 2013.
manual_line.key
is the example that is included in the spectral line section of this manual. It is for VLBA and GBT observations of 7mm SiO lines. It is more complicated than egOH.key and also demonstrates setting GBT frequencies and many other setup parameters that were defaulted in egOH.key. This file has not been updated from MARK5A to MARK5C.
eg512.key
is a sample schedule for the VLBA that uses the 512 Mbps mode.
eg512g.key
is a sample schedule for the a global observation that uses 512 Mbps with the RDBE.
eg1024.key
is a sample schedule for the EVN that uses the 1024 Mbps mode with DBBC, VLBA4, and MKIV systems.
eg2head.key
is a sample schedule for an EVN observation that uses the 512 Mbps mode. This uses 2 heads on one tape drive on Mark IV stations. VLBA4 and DBBC stations are included. Note that it is possible to do 512 Mbps on the VLBA and Mark IV stations simultaneously. The VLBA uses 2 drives while the Mark IV systems use 2 heads. This is actually based on a network monitoring observation.
egglobal.key
is a sample file for simple continuum observations involving the VLBA, the EVN,and the GBT. The VLA has been removed because this example uses the legacy recording system which is no longer supported at the VLA. This file has not been updated from MARK5A to MARK5C.
egglobalOH.key
is a sample file for line observations involving the VLBA, the EVN,and the GBT.
egvsop.key
is a sample schedule for Mark IV / VLBA observations specifically using modes appropriate for observations with the Japanese VLBI satellite, VSOP. It will produce VEX format schedules for stations that use the field system and VLBA format files for those stations that need them. VSOP (HALCA) is no longer operational, but the VSOP-2 project has started so this example has been retained. It will be modified for VSOP-2 when that project is far enough along to make it clear what is needed. This file has not been updated from MARK5A to MARK5C.
eg3mma.key
is a VLBA schedule for observations at 86 GHz. There is special emphasis on reference pointing, which is done explicitly in this file. This file uses the RDBE_DDC at 2 Gbps using 8 channels of 64 MHz each.
eg3mmb.key
is another 2Gbps VLBA schedule for observations at 86 GHz. There is special emphasis on reference pointing, which is done automatically in this file based on information in the peak.cmd file.
eg3mmc.key
is yet a third VLBA 3mm schedule, again using automatic insertion of pointing scans. But this time, the file with the commands controlling that insertion is inserted in the main schedule file and is somewhat simplified from that in eg3mmb.key This file does not create the separate new and old system files needed for reference pointing on masers while observing with the new RDBE wide band system with the PFB personality. For instructions on how to do that, please see eg3mm_rd2.key. This file has not been updated from MARK5A to MARK5C.
eg3mm_rd2.key
is similar to eg3mmb.key, but shows how to make reference pointing observations, when using the RDBE wide band system with the PFB personality which uses fixed 32 MHz channels and cannot be fine tuned. It uses the crd parameters to specify the allowed bandwidth and frequency, including using Doppler calculations, to set the legacy system as desired.
vips11.key
shows use of OPTMODE=HAS for automatic scheduling. This mode tries to obtain a requested number of scans on each source and spread them reasonably evenly over the time available. It pays some attention to minimizing slew times. It is meant to simplify scheduling of projects that try to image a number, perhaps large, of sources using multiple snap-shots on each. It was originally provided for the VIPS project but should be useful for many other programs.
evn_cont_strong.key
is an example of EVN observations at 18cm. The observing pattern is an 11 minute cycle with 2 minutes on a calibrator and 9 minutes on a target source. This observation is at 128 Mbps.
evn_cont_strong_pol.key
is essentially the same schedule as evn_cont_strong.key, but with a D term calibrator and a polarization position angle calibrator added.
evn_cont_weak_256.key
is phase referencing schedule for the EVN with a 5 minute cycle time using 256 Mbps.
evn_cont_weak_512.key
is a similar phase referencing schedule for the EVN, but uses 512 Mbps which requires 2 headstacks.
evn_cont_weak_snap.key
is an EVN schedule for 256 Mbps observations of multiple snapshots using phase referencing.
evn_line_hi.key
is for EVN observations of an extragalactic 21-cm HI source.
evn_line_meth.key
is for EVN only observations of the 6.7 GHz line of methanol in a galactic source.
eg5cm.key
is a sample schedule for the EVN and EVLA that observes near 6.7 GHz. It is the same as evn_line_meth.key, but with the EVLA added.
egmk5vex.key
is for EVN only observations using the Mark5 system. It is based on a Network Monitoring schedule. Note that it is a bit dated in that it uses the Mark5A system for a VLBA station which no longer has that option.
hsa1cm.key
is a sample schedule for the High Sensitivity Array (HSA - VLBA + GBT + Effelsberg) at 1cm. This file does not include the VLA and Arecibo.
hsa21cm.key
is a sample schedule for the High Sensitivity Array (HSA = VLBA + GBT + Effelsberg + Arecibo (VLA removed)) at 21cm. The schedule uses the legacy system which is not available at the VLA so the VLA has been taken out for now.
hsaddc.key
is a rather complex example that uses the RDBE with the DDC personality on the VLBA, VLA, GBT, and Effelsberg. There are segments at 6cm, 1cm, and 3mm. It exercises array phasing at the VLA, reference pointing at all of the telescopes, and Doppler tracking.
lba.key
is a sample schedule for the Long Baseline Array in Australia.
lba_h20.key
is a sample schedule for the Long Baseline Array in Australia using LBA DAS/Recorder only. Observations are at the 22 GHz water line.
lba_oh.key
is a sample schedule for the Long Baseline Array in Australia using LBA DAS/Recorder only. Observations are at the 1.8 GHz OH line.
lba_mk5.key
is a sample schedule for the Long Baseline Array in Australia when some MARK5 stations are included.
planvla.key
is a planning file similar to the other VLBA planning files, but has all 27 stations of the VLA A configuration. You can use this to explore VLA uv coverage etc. It should still work despite the current (2014) inability to schedule the VLA for other than VLBI. It doesn’t actually create observing files.
doptg.com
is a script that creates and runs VLBA pointing observations. It exercises one of the optimization modes to allow the same script to be used for any time slot for any time of year. This example will not be run by the Verify script if the site is not at NRAO because the ephemeris routines used for pointing at planets will not generally be available. It is also not of much interest beyond the staff responsible for maintaining the VLBA.
doptg2.com
is a script that creates and runs VLBA pointing observations. It is very much like doptg.com except that it uses the DOSTA parameter to allow the same script to be used for stations with 3mm and stations without 3mm.
egsat.key
demonstrates scheduling a satellite observation using both MER-B and Stardust. It also includes Mars to exercise the planet option. These capabilities are unlikely to be of interest outside of the AOC. In fact, the required NAIF software libraries would hugely increase the size of the SCHED distribution and are not normally included. This file has not been updated from MARK5A to MARK5C.
dq415.key
is a data quality test file from early 2014 that uses the RDBE and MARK5C. It samples most of the RF bands available on the VLBA.
mt506.key
is one of the weekly VLBA integrity check observations from the MARK5A era. It is here mainly to exercise SCHED in a mode that uses lots of setup files. It is similar to the more modern dq415.key but uses the outdated recording system. It should probably be removed soon.
jvla.key
is an example covering use of the VLA as a phased array for VLBI. This version uses the 32 MHz output baseband bandwidths of the WIDAR to create recordings that can be played against 4 of the 16 channels created by the PFB personality of the RDBE on the VLBA.
n2227.key
is a sample USNO Earth Orientation observation using PT and MK.
pfbsettst.key
is a vehicle for testing all the new RDBE/MARK5C standard setup files that use the pfb personality. These are the setups that start with rdbe_pfb.
egsat.key
is a sample VLBA observation of spacecraft with bsp ephemeris files. Note that the satellite tracking in SCHED uses the NAIF software from JPL. The object libraries for linux g77 and gfortran are included with SCHED, but may not be usable on all machines. The code is not exported. Normally, other than in the AOC, the stub routines are used and SCHED cannot deal with satellites. Also, SCHED does not have a way to pass the necessary site dependent, moving source positions to non-VLBA stations.
tlesat.key
is a sample VLBA observation of spacecraft using TLE ephemeris files. See the note above (egsat.key) about the satellite tracking software. It applies here too.
newsyn.key
is a VLBA test observation to check the performance of the new front end synthesizers being designed in 2013-2015. Those synthesizers have finer tuning steps than the current ones (10kHz vs 200 or 300 MHz). They are not yet deployed except at a couple of sites so this example is not yet of interest to users.
tstsets.key
is a VLBA test observation that tests the standard setups used with the RDBE/DDC. Only bit rates under 512 Mbps are tested. This is not a maintenance schedule, not one users would likely want to emulate.
piggyback.key
is a VLBA test observation that observes with both the Mark5A and Mark5C systems. As of early 2015, only two VLBA stations even have Mark5A so this is only of interest to VLBA testers.

1.4.1 A Basic VLBA Schedule.

The following example gives a fairly typical schedule that relies on SCHED’s defaulting schemes and standard catalogs to get most of the required information. The cover and correlator information cannot be reduced nor can the individual scan information. All of those inputs are unique to the observation. This example is probably the most useful one for users to use as a template for making their own VLBA schedules, including for observations that include the VLA. It used to produce the same schedule as manual_1.key but that example actually shows how many items, that are defaulted or taken from standard catalogs here, can be specified in the schedule file. More recently (late 2012), manual_1.key was converted to use the wideband RDBE system. Note that manual_2.key has not yet been updated from MARK5A to MARK5C.

!  BE002 example of 3C84 observations at 6 and 4 cm.  
!  
!    This example used to produce the same schedule as manual_1.key  
!    but uses many SCHED defaults and is missing most comments.  
!    It shows approximately the sort of file a users would  
!    normally make.  Note that all catalogs are defaulted.  
!  
!    On Nov. 1, 2012, this example was modified to use the GBT  
!    rather than the VLA which can no longer do legacy style  
!    observations.  Eventually it, like manual_2.key, will be  
!    moved to the new wide band systems.  
!  
overwrit  
! ==========================================================  
! =================  Cover Information  ====================  
! ==========================================================  
 
version  = 1  
expt     = ’Example: 3C84 6, and 4 cm’  
expcode  = BE002  
obstype  = VLBA  
 
piname   = ’Craig Walker’  
address1 = ’National Radio Astronomy Observatory’  
address2 = ’P. O. Box O’  
address3 = ’Socorro, New Mexico, 87801’  
address4 = ’ U.S.A. ’  
phone    = ’505 835 7247 ’  
obsphone = ’505 835 7247 ’  
email    = ’cwalker@nrao.edu’  
fax      = ’505 835 7027 ’  
obsmode  = ’Continuum’  
correl   = ’Socorro’  
note1    = ’ ’  
 
! ==========================================================  
! ==============  Correlator Information  ==================  
! ==========================================================  
 
correl   = ’Socorro’  
coravg   = 4  
corchan  = 16  
cornant  = 10  
corpol   = ’on’  
corwtfn  = ’uniform’  
corsrcs  = ’SCHED’  
cortape  = FTP  
corship1 = ’Craig Walker’  
corship2 = ’P. O. Box O’  
corship3 = ’Socorro NM 87801’  
cornote1 = ’ ’  
!  
 
! ==========================================================  
! ======= Standard Source and Station Catalogs  ============  
! ==========================================================  
! Standard source catalogs are sources.gsfc and sources.rfc.  
! This schedule uses some aliases only in sources.gsfc.  
srcfile  = $SCHED/catalogs/sources.gsfc  
stafile  = $SCHED/catalogs/stations.dat  
freqfile = $SCHED/catalogs/freq.dat  
 
 
! ==========================================================  
! ==================== Setup Information ===================  
! ==========================================================  
!  The first setup file shows the bare minimum that needs to  
!  be specified.  Essentially all of this information would  
!  be needed to choose one of the standard setup files.  This  
!  one would correspond to v6cm-64-4-1.set, with a possible  
!  slight frequency offset between what is in the specific  
!  "standard setups" and what is generated using BAND=6cm.  
 
setinit = v6cm.set /  
   nchan    = 4  
   band     = ’6cm’  
   bbfilter = 8.0  
   bits     = 1  
   pol      = dual  
   /  
endset /  
 
!  For the second example setup, the user forces the  
!  frequencies, BBC’s, sidebands, and format.  It still  
!  relies on the frequency catalog for the IF assignments  
!  and for many VLA parameters.  There are a lot more  
!  parameters that could be forced in extreme cases.  
 
setinit = v4cm.set /  
   nchan    = 4  
   freqref  = 8416.99  
   freqoff  = -3.5, -3.5, 4.5, 4.5  
   bbfilter = 8.0  
   bits     = 1  
   bbc      = 1,    2,    3,   4  
   netside  = U,    U,    U,   U  
   pol      = RCP,  LCP,  RCP, LCP  
   format   = VLBA1:4  
   /  
endset /  
 
! ==========================================================  
! ========================  The Scans  =====================  
! ==========================================================  
year  = 1995  
month = 10  
day   = 22  
start = 01:30:00  
 
!  Note use of station codes.  Names could also be used.  
stations = SC, HN, NL, FD, LA, PT, KP, OV, BR, MK, GBT_VLBA  
 
Source = 3C454.3   Dur   = 5:30   Setup = v6cm.set    /  
Source = 3C454.3   Dwell = 5:30   Setup = v4cm.set /  
 
stations = SC, HN, NL, FD, LA, PT, KP, OV, BR, GBT_VLBA  
 
group 4 rep 14  ! About 3 hours in 12 repeats of the next 4 scans.  
Source = 3C84      Dur   = 3:00  gap = 2:00  Setup = v6cm.set /  
Source = 3C84      Dwell = 3:00  gap = 0     Setup = v4cm.set /  
Source = 0309+411  Dwell = 2:00  /  
Source = 3C84      Dwell = 3:00  /  
 
!  Add MK  
stations = SC, HN, NL, FD, LA, PT, KP, OV, BR, MK, GBT_VLBA  
 
group 4 rep 14  !   About 3 hours.  
Source = 3C84      Dur   = 3:00  gap = 2:00  Setup = v6cm.set /  
Source = 3C84      Dwell = 3:00  gap = 0     Setup = v4cm.set /  
Source = 0309+411  Dwell = 2:00  /  
Source = 3C84      Dwell = 3:00  /  
 
group 8 rep 15  !  6.5 hours  
Source = 3C84      Dur   = 3:00  gap = 2:00  Setup = v6cm.set /  
Source = 0552+398  Dwell = 3:00  gap = 0     /  
Source = 0552+398  Dwell = 2:00  gap = 0     Setup = v4cm.set /  
Source = 3C84      Dwell = 3:00  gap = 0     /  
 
Source = 3C84      Dur   = 3:00  gap = 2:00  Setup = v6cm.set /  
Source = 3C84      Dwell = 3:00  gap = 0     Setup = v4cm.set /  
Source = 0309+411  Dwell = 2:00  /  
Source = 3C84      Dwell = 3:00  /  
 
Source = 3C273     Dur   = 5:30  gap = 3:00  Setup = v6cm.set /  
Source = 3C273     Dwell = 5:30  gap = 0:00  Setup = v4cm.set /  
 
! ==========================================================  
! ========================  End of example  ================  
! ==========================================================

1.4.2 A Minimal Schedule for Planning.

SCHED input files can be simple for simple situations. The following file is about as simple as a SCHED file can get. It is set up for exploring the u-v and sky coverage, and times of availability, of a list of sources using the plotting abilities of SCHED and using the UPTIME optimization mode to give overlapping 24 hour schedules for each source.

!----------------------------------------------------------------------  
!  Example of very simple SCHED file - for making uv etc plots.  
!----------------------------------------------------------------------  
overwrit                 !  Allow writing over old output files.  
expcode  = UVCOV         !  Needed for name of summary file.  
obstype  = NONE          !  No tape recording.  
nosetup                  !  No setup file.  
optmode  = uptime        !  Planning mode.  
opdur    = 24:00:00      !  Look at a whole day.  
opminant = 4             !  Minimum number of antennas that must be up.  
opminel  = 15            !  Don’t include scans below this elevation.  
year     = 1996  day = 1 !  Year and day.  
start    = 00:00:00      !  Start time for plots.  
dur      = 10:00         !  Ten minute scans.  
stations = SC, HN, NL, FD, LA, PT, KP, OV, BR, MK  
source   = DA193 /  
source   = 3C120 /  
!----------------------------------------------------------------------  
! End of example.  
!----------------------------------------------------------------------

If the above file were named uvcov.key, it could be run with the commands:

sched  
plot sch=uvcov.key /

When the plot section is reached, a graphical interface will appear that is reasonably obvious how to use.

1.5 Plotting

SCHED has the ability to plot the u-v coverage and beam of sources in a schedule and to plot azimuth, elevation, hour angle, or paralactic angle against any of those quantities or against UT or GST for one to all stations in a schedule. These plots are useful for assessing the quality of the schedule. SCHED can also plot the positions of the sources in a schedule in RA and DEC and plot the positions of all other sources in the specified catalog. The latter is useful for identifying candidate calibrators. The plots can be very useful for planning observations, both at the proposal stage and as the schedule is prepared. For this use, see the section on planning and for a very simple example schedule for obtaining plots of hypothetical schedules, see the second example in the Examples section. Some of the other examples are also oriented toward planning VLBA and VLA observations.

To cause SCHED to make plots, specify PLOT somewhere in the input. Since it is unlikely that this will be desired in the final run of the program, it is best to start a plotting session interactively and then specify PLOT and use SCHedule to specify the input file. Thus, you would type (on a unix box, anyway):

sched  
plot  schedule=bv016d.key /

(substituting your file for the bv016d.key.

The plotting utilizes the PGPLOT subroutine library written by Tim Pearson used by the other Caltech Package programs and in wide use in astronomy. Be sure that the environment variables PGPLOT_DIR is set to the location of the PGPLOT libraries on your system and that PGPLOT_FONT is set the the location of the PGPLOT font files if that is different from PGPLOT_DIR.

If PLOT has been invoked, SCHED will proceed to read all of the input files, check the schedule, and do any requested optimization normally. It will write the summary file, but will not write the antenna specific files, at least until later. The summary file will be closed and can be examined while in the plotting session. This may be useful in studying details of what is being plotted.

When the plotting session begins, SCHED opens a control panel with a variety of buttons that can be clicked with the mouse. It also writes some instructions to the window in which SCHED is being run. On the control panel, the left most column has buttons that either select different control functions (items to the right will change) or cause something to happen. The latter options include actually drawing a plot (PLOT), closing the plot (CLOSE), restarting the program to read a new input file (RESTART), continuing to (FINISH) the rest of SCHED (only allowed if neither RESTART or OPTMODE=UPTIME were used), exit the program (EXIT), or revert the the older style terminal input (TERM) described below. The FILES options allows changing output from the terminal to postscript or other files and allows restriction of plots to scans with specific setup files. The OPTIONS button allows selection of colors and line widths. The AXIS button allows selection plot type and axis scales. The SOURCES button (default on wakeup) allows selection of antennas and sources. Antennas can be selected both for plotting at all and for highlighting in red. The use of the buttons should be fairly intuitive and won’t be documented extensively here. Some information included in the descriptions of the terminal input below also applies to interactive operation so it is worth reading through the documentation quickly.

Many thanks to Franco Tinarelli of Bologna for providing the code for the plot control.

Note that, if elevation is plotted against azimuth, the horizon, as specified in the stations catalog, will be plotted in addition to the tracks followed by the sources.

If the RD Plot option is selected, the location on the sky of each source in the schedule is shown. This particular plot option has acquired a number of interactive capabilities. It is possible to zoom in on a region, to look for calibrators around a target location, to show (as calibrators) all sources in the catalog, not just those listed in the schedule, and to label the source and catalog names. These capabilities should be useful in attempts to locate calibrators near reference sources. Currently, a rectangular coordinate system is used for the displays, but a more general projection scheme is under development.

Plots are made, of whatever quantities are specified, by drawing a line from the value at the beginning of each scan to the value at the end of the scan. Thus, if you have very long scans, the individual line segments may become apparent and the plot will not be an exact representation of the data that will be collected.

The RESTART option is especially interesting for experiment planning. It causes SCHED to return to the beginning of the program, read and process the input file again, and return to the plot section, remembering the current plot inputs. If the input file has been changed in any way, those changes will be reflected in the new plots. Thus scan times can be changed, new sources specified etc. This is useful, for example, in exploring the u-v coverage for various sources (much like the Caltech program HAZI) or determining the times that various sources are visible (like the Caltech program UPTIME). It is more flexible than the other programs because you have full control of the schedule so, for example, the u-v coverage from multiple snapshots can be explored. Because it is possible, by deleting some parameters from the input file, to cause SCHED to get confused about the value of some of the parameters for which only one value per project is accepted, the FINISH option is locked out after a RESTART. If a RESTART option has been used, it will be necessary to rerun the program from scratch to get final output schedules. Since you have been modifying the input file on each restart, this should not be a problem.

In older versions of SCHED or if the TERMINAL button is pressed, the plot control is from the terminal window using KEYIN input as described below. This form of input will probably be removed eventually unless there is demand to keep it.

1.5.1 Keyin Input for Plotting (obsolete)

This section describes the use of Keyin inputs to control the plotting functions. This has been superceded by the control panel scheme of inputs, but the documentation will be retained until the capability is removed.

If the TERMINAL button is pressed on the plot control panel, SCHED reverts to Keyin style input from the main window in which it is running to control the plots. First, SCHED writes a description of the possible input parameters, which are also described below, and then prompts for KEYIN style input. The user should specify any desired quantities and then type a “/”. If the user is on a machine with X windows graphics, simply taking all the defaults will cause a u-v plot of all sources and scans in the project to appear on the screen.

The inputs can be used to choose between u-v plots, xy, and Ra-Dec plots. For u-v plots, the scale can be specified and a station can be selected for which, on color displays, the baselines to that station will be highlighted (displayed in red). Also the source to be plotted can be specified. XY plots are a bit more complicated because they are more flexible. The quantity to plot on each axis can be selected, the scales specified and the station and source chosen to be one or all. See the details of the input parameters below. In addition, the plot can be restricted to scans that use one of the setup files. This can be useful for assessing band switching observations.

The input parameters are not reset between runs of the plotting. Thus the user need only specify those items that he/she wishes to change. Some of the built in KEYIN capabilities can be useful here. If you type SHOW, KEYIN will list the input variables and their current values. HELP generates a list of the variables. Also you can type SAVE filename and KEYIN will write a file with name filename in the default area containing the current parameter settings. Later, perhaps in another run of SCHED, you can type @filename to recover those parameters. The parameter file can be edited — it is a normal KEYIN input file (actually any file can be read with the @filename construct, although only up to the first “/”).

Plotting Input Parameters (Terminal):

The KEYIN inputs to the plotting section of SCHED are:

PLotfile

PLOTfile gives the output specification for the plot. As with any PGPLOT programs, it is in the form filename/device. For interactive devices, the filename need not be specified. The default device is /xs which is a good choice for X windows systems. Other devices most likely to be of interest are /ps for a postscript file and /cps for a color postscript file. See PGPLOT documentation PGPLOT documentation for other options (more will be listed here in the future). The device can be changed at any time. If it is changed, the old one will be closed and the new one opened. This allows the plot to be set up interactively, and then put out in postscript for printing.

SEtnum

When the plotting section is entered the first time, information is written to the screen about possible input options. Among the information presented is a numbered list of the setup files encountered in the input. With SEtnum, one of those setup files can be selected by number (avoids lots of typing since setup file names often include full paths and can be quite long). Then the plot will only show scans which use that setup file.

TYpe

TYpe is used to specify the type of plot. The option are UV, which is the default, XY, and RD. UV causes a plot of the spatial frequency coverage to be plotted. For now, the scale on the plot is km. An expected enhancement eventually is for this to optionally be in wavelengths. For XY plots, there are a variety of options which are specified with XAxis and YAxis, which independently specify the quantity plotted on each axis. RD requests that the locations of the sources in the schedule be plotted in Ra and Dec.

XAxis

XAxis specifies the quantity to be plotted on the horizontal axis in a TYPE=XY plot. The options are el for elevation, az for azimuth, pa for paralactic angle (for polarization), ha for hour angle, ut for universal time, and gst for Greenwich Sidereal time.

YAxis

YAxis specifies the quantity to be plotted on the vertical axis in a TYPE=XY plot. The options are el for elevation, az for azimuth, pa for paralactic angle, and ha for hour angle. If xaxis=az and yaxis=el, the antenna horizons will be plotted along with the source tracks.

XLeft and XRight

XLeft and XRight specify the minimum and maximum for the X axis plot scale. If they are not set, or are set to -9999., the axis will be autoscaled. For u-v plots, it is only necessary to specify one value, say XMax, and it will be used for all 4 limits. If more than one are specified, they are used which allows off center plots. For XY plots, the limits should be specified in the units of the plots. For the time axis, the limits should be in the form hh:mm:ss where this is the time offset since the beginning of the first day of the experiment for UT or is the GST. Note for u-v plots, traditionally, the plot has positive to the left so XLeft will be greater than XRight. For Ra-Dec plots, XLeft and XRight specify the RA range and should be in the form hh:mm:ss (eg. XL = 5:30:00).

YBottom and YTop

YBottom and YTop specify the minimum and maximum for the Y axis plot scale. If they are not set, or are set to -9999., the axis will be autoscaled. For Ra-Dec plots, YBottom and YTop specify the declination limits and should be in the form dd:mm:ss (eg. YB = -12:15:00).

SOurce

SOurce can be used to restrict the plots to a single source. The default, which can be specified at any time is ALL, which will cause all sources to be plotted.

STation

STation can be used to restrict TYPE=XY plots to one station. For TYPE=UV plots, all stations will be plotted, but all baselines to the specified station will be plotted in a contrasting color. The default, which may be specified at any time, is ALL, which will cause all stations to be plotted or not highlighted.

REstart

See the discussion above for details of the effect of REstart. In short, it causes the program to return to the beginning and reread the input, which may have changed.

FInish

FInish tells SCHED to close the plot files and produce the station specific output files. FInish is locked out after a REstart to make absolutely sure that the output files really correspond to what is in the schedule file. If REstart has been used, it will be necessary to EXit and rerun SCHED from scratch to get the station output files.

EXit

EXIT tells SCHED to close the plot files and exit. Antenna specific files will not be produced.

Chapter 2
INFORMATION AND ADVICE ON SPECIFIC TOPICS

2.1 Using SCHED for Project Planning

The plotting and summary capabilities of SCHED make it useful for experiment planning. When writing a proposal, it can be used to determine the appropriate GST ranges for a source and to explore the u-v coverage available. While designing a schedule, it can be used for the same purposes and to experiment with various detailed schedules. It is also possible to plot the distribution on the sky of sources, either just the sources in the schedule, or, in addition, all of the sources in the catalog. This might be useful for selecting calibrators.

The most effective use of SCHED for planning involves using 5 windows on a windowing system. The first is the one in which SCHED was started. The second is the plot control panel brought up by SCHED. The third is the actual plot window used by SCHED. The fourth is your favorite editor in which changes to the main SCHED input are being made between REstarts. The fifth has some sort of listing tool, such as more or less in unix, which can be used to examine the summary file.

The schedule to use for planning can be very simple. In fact the simple example at the end of the Examples section is designed exactly for this purpose. One of the other examples, egplan.key is also well set up for this. Multiple sources can be specified, or a REstart can be done after editing in each source that is to be examined. The optimization mode UPTIME is especially useful for planning. Also, if you are trying hypothetical stations, or stations for which you don’t have setup information and which are not in the frequency file, you may wish to use NOSETUP to completely turn off all need for setup information (of course, you cannot then write telescope control files with NOSETUP active).

2.2 Scheduling Tips

This section contains subsections with detailed discussions and advice on various aspects of scheduling. It surely is not complete, but much basic advice is available.

2.2.1 Observing Strategy

A tremendous amount could be said about observing strategy. See the article by Joan Wrobel in the book “Very Long Baseline Interferometry and the VLBA” (1995: ASP) for a good discussion. That book also contains a lot of information about VLBI and is a good reference for all observers to have. Other important sources of information are the “VLBA Observational Status Summary” and “General Instructions on Observation Preparation” (which is sent to scheduled users). These and many other useful documents can be accessed on the Internet from the “VLBA Information for Astronomers” page. This section of the SCHED Manual will be limited to a few important concepts to keep in mind while scheduling. It is assumed that the observer already has a reasonable idea of how much time is needed per source, what frequencies to observe, etc. The suggestions here are more oriented toward smooth observing, processing, and calibration.

Fringe finders: In order for the staff at a VLBI correlator to tell if the correlation has gone well, it is necessary to have occasional scans on sources that will provide strong fringes. A minimum of two such scans should be provided and, for longer projects, there should be one every 4-6 hours at a minimum. The “VLBA Observational Status Summary” and “General Instructions on How to Prepare for Observing” documents mentioned above have lists of appropriate sources.

The fringe finders can also be used for “manual phase cal”. This is the process of aligning the phases and delays on all individual IFs. This is simply done by running the fringe fitting program on the calibrator and applying the results to all data. For this purpose, it helps to have a scan with all antennas at reasonably high elevations simultaneously.

Finally the fringe finders typically make good bandpass calibrators because then have good SNR in each spectral channel.

Setting the flux scale: Setting the flux scale of VLBI images is not trivial. Ideally, one would have a compact source of known flux density that could be used, as 3C286 and 3C48 are on the VLA, to calibrate the flux densities. However, by their nature, sources that are compact to VLBI (essentially none are unresolved) are variable and, therefore, do not make good flux calibrators. There are two ways to deal with this.

One is to try to obtain the flux density of a compact calibrator at a close enough time to the VLBI observations that variations will not be significant. At the time of the VLBI observations, some of the larger antennas can be asked to measure flux densities of sources being observed (see the TANT command. Better yet, if you have a phased array, such as the VLA, or can get an hour or so of VLA test time, accurate flux densities of your VLBI calibrators can be measured. In order to do this, be sure to include a VLA flux calibrator (usually 3C286 or 3C48) in the VLA schedule. You don’t need to record VLBI data on it. This method can go awry if the calibrator has intermediate scale structure that is compact to the interferometer but resolved out by VLBI.

It is also possible, and perhaps preferable, to rely on the apriori calibration of the VLBI antennas. For this, it is best to look carefully at your data and determine which subset of antennas is giving consistent calibration. With the VLBA at intermediate frequencies, it is possible to get the flux scale right to within a few percent this way. You just have to be sure not to let any antennas with bad weather or other problems contribute to the flux scale. In the AIPS calibration task CALIB, use ANTUSE to limit the gain normalization to the antennas whose gains you trust. Also specify a generous minimum elevation, such as 30 degrees, for the gain normalization.

When using the apriori gains for absolute flux calibration, care must be taken with bandpass calibration and channel selection. The gains are measured using the full bandwidth of the baseband channel - they are based on total power measurements from the baseband converters. Such gains apply to the average across the full baseband. If you attempt to apply such gains to a data set with the edge channels removed, there will be an error of a few percent because those edge channels typically have lower gain (which is probably why you removed them) and the average for the remaining channels will be higher. You can deal with this either by doing the calibration including all edge channels, or by doing a bandpass calibration based on all channels. Bandpass calibration brings all channels to the average level.

If you are going to rely on apriori calibration, be sure to obtain some data at close to the frequencies at which antenna gains have been measured. These frequencies are given in the vlba_gains.key available by anonymous ftp to ftp.aoc.nrao.edu. This is the file that you will need for VLBA calibration. At those frequencies, the Tsys used in calibration and the gain are based on the same values of Tcal so the Tcal value cancels out. If you observe at other frequencies, you will be depending on the Tcal values being correct (or at least having the right ratio) at your frequency and the frequency where the gains are measured. That is not assured.

For any of these methods to work, it is best to include a strong, compact calibrator and to observe it several times to check consistency.

There appears to be an offset of on the order of 6.5% between Tsys values measured with the legacy VLBA system’s baseband converters and Tsys measured with the new, wide-band RDBE. The cause of that offset is not yet understood, but is thought to be some issue with the old system. During the transition, the gains distributed are for the old system. An adjustment appears to be required to for data data calibrated using Tsys measured either by the RDBE or by DiFX and gains derived from the old system (all gains distributed so far as of July 2012). For a discussion of this effect, see /htmladdnormallinkVLBA Senesitivity Upgrade Memo 34 https://science.nrao.edu/facilities/vlba/publications/memos/sensitivity-upgrade/index.sensimemo34.pdf. Stay tuned on developments in this area.

“VLBA Information for Astronomers”

Setting the relative gains of antennas: Another invaluable use of a strong, compact calibrator is to help ensure that all antennas and all IFs have consistent calibration. After apriori calibration and setting of the flux scale has been done, a model of the calibrator can be used to derive whatever additional gain adjustments are needed. These can be applied to the whole observation to obtain the best possible calibration, short of self-cal.

Scan Gaps, “Readback tests”, and module-swap gaps: Before the Mark5C era, one had to be very careful about scan gaps to avoid data loss due to resync times, but also not to put the data at risk through excessively long record scans (period of no media stoppage). With the Mark5C, most of these issues go away. The media are stopped from the end of one scan to the expected time of good data at that station in the next scan. Resyncs don’t take time with the software correlator.

With the older media (including currently (2012) in use Mark5B and VLBA disk recording), the recording media should be stopped occasionally to help prevent major amounts of data loss if something should go wrong and, on non-VLBA controlled stations, to allow disk bank changes. Two minute gaps every hour or two used to be used for readback tests with the tape systems. Tape is no longer used, but an equivalent data integrity test is likely to be built into the disk based systems in the future. Also, if the disks are not stopped, all the data ends up in one file. If there are problems closing the file, the data can become unreadable. As of early 2008, it is recommended that a gap of 30s or more be inserted every hour or two. In fact, any pause in recording will start a new recording scan, but beware that SCHED prevents gaps of less than MINPAUSE seconds. For field system controlled stations, (most non-VLBA stations) gaps should also be inserted to allow bank changes. The VLBA can switch between mounted disk banks (modules) on the fly, but the field systems need a pause in the data recording. Such gaps should be inserted every 22 minutes for recordings at 1 Gbps and proportionally less often at lower bit rates. These gaps need to be more than 10s long.

Phased VLA: The phased VLA has special calibration needs. If the target source is either too weak or too resolved to be used for phasing up the array, special scans on a calibrator must be inserted for this purpose. This can be done with SCHED . Or it might be possible to do it with the VLA scheduling software, but it is probably better to explicitly include the calibrators in the SCHED files. (see the section on VLBI at the VLA for details).

Also, the effective beam of the phased VLA (or any other phased interferometer such as Westerbork) is the synthesized beam. This can be less than an arcsecond in the worst cases. This places far greater demands on source positions required for observing than is typical at single antennas. Be sure to provide positions of sufficient accuracy, which can mean 0.1 arcsecond.

Anyone using the VLA for VLBI should consult the VLBI at the VLA guide.

Calibrator scans: Except for phase or fringe reference calibrators, there will typically be only 2 or a few more scans on each calibrator of the types discussed above. It is tempting to put these scans at the beginning and end of the scheduled observing time. However this is quite risky as those are the time periods most likely to experience problems. The beginning is especially risky because, if there are any problems at a site, they may not have been fixed yet. The end is ok, except at sites where the main target source has been down for a while and the antenna has been idle. It may not wake up again cleanly for the calibration scans. It is best to take time (a few minutes on each calibrator) out of the middle of the schedule a couple of times to get the calibration data.

Protected scans: Starting in Oct. 2011, ongoing VLBA observations will be preempted at the Pie Town and Mauna Kea stations once per day for up to 1.5 hours for Earth Orientation Observations. This is in return for operations funding from the USNO. There is some flexibility in the exact times of the preemption. SCHED parameter PREEMPT can be used to protect key scans such as special calibrators or geodetic segments. See the writeup for that parameter for more details.

24 hour schedules: With dynamic scheduling, it is useful if 24 hour schedules can be “wrapped” by starting part way through, then picking up the first scans at the end. If you have a 24 hour schedule, it would help the process if you insert a unique COMMENT at the logical places for wrapping the schedule. The scheduler will use the WRAP24 switch to cause SCHED to copy the scans onto the end of the schedule to create a 48 hour schedule. He/she will then use DOSCANS to select the desired 24 hour block. Unique comments help find the same place in the two copies of the schedule. Example eg24.key demonstrates such a schedule.

Set-and-remember: Both the VLBA (RDBE) and the VLA new systems require the power levels for the analog signals to be set before the wide band samplers. Changing the attenuators can cause phase errors, but there is a lot of dynamic range in the allowed levels. Therefore the attenuators are only set once for each frequency setup per observation. Time needs to be left for that operation. The RDBE needs 5 seconds. The VLA needs 60 seconds. SCHED will warn when inadequate time is provided. Also, SCHED will schedule in the required time automatically using the numbers in the station catalog parameter TLEVSET when using dwell time scheduling when the scan itself is a recording scan, a pointing scan, or a phasing scan (VLA) or is not long enough. After the first scan with a setup, the RDBE/PFB needs about 2 seconds at the start of each scan to set the levels for the final down-sampler to 2 bits. That time will be provided automatically for if the station file parameter TSETTLE is higher, which it normally is for other reasons. For the DDC personality, the level setting will be adjusted regularly during the scan. The VLA doesn’t need extra time for that, although that operation is done.

2.2.2 Scan Times

Scans have a nominal start time and a stop time that may be set explicitly by the user or derived by SCHED based on a variety of criteria. Scans have a separate start time, often offset from the nominal start time, that SCHED assigns for the start of recording. SCHED also has a reasonably good idea of when good data will start to be available after any required slews and setup times are completed. Throughout most of SCHED, the scan times presented to the user are the nominal start and stop times. On the other hand, the recording start time is what will be given in the files sent to the telescopes and correlators. The VEX file, which is becoming dominant as the telescope and correlator control file, uses the recorder start time as the scan time, but contains the offset from that to the good data start. Some systems, including the VLBA and VLA now use the good data start as the time to start recording or correlation. This section describes how all this is controlled using a number of SCHED input parameters.

There are a variety of ways to set the nominal times of a scan. A START time must always be set for the first scan of a schedule — SCHED obviously has to know when to start. After that, the ways to set the nominal scan times are:

Set the START time and the STOP time. This is uncommon except with SCHED inputs derived automatically from other sorts of schedules.

Set just the STOP time. SCHED will use the previous scan’s stop time plus any gap as this scan’s start time.

Set the START time and the DURation. Sched will set the start time as requested and the stop time to the start time plus the duration.

Set a duration using DURation. SCHED will set the start time to the previous scan’s stop time pus any GAP and the stop time to the start time plus the duration.

Set a duration using DWELL. SCHED will set the start time to the previous scan’s stop time plus the time it takes to get the antennas on source and observing. Then it will set the stop time to the start time plus the requested dwell time. Note that this option does not yet take into account the time to switch between frequency bands (say 7mm to 2cm). There is an option, with a second argument to DWELL, to not wait for the last, or last few antennas. This can be useful when there is a slow antenna involved or when some antenna is too close to the zenith. A third argument can be used to insure that the slow antennas get some time on source. GAP can be used to set the minimum interval between the scans. This is the most recommended scan scheduling scheme.

Use any of the above to set the start and stop times, and then offset the resulting start time with PRESCAN. Only the start time, not the stop time, is affected by PRESCAN. If PRESCAN is positive, the start time is delayed. If PRESCAN is negative, the start time is moved earlier by the requested amount, although it will not be moved into the previous scan. This used to be the primary scheme for controlling time provided for media acceleration and correlator synchronization, but has been superceded by GAP, PRESTART, and MINPAUSE. A still-useful function is to delay the start of scans scheduled with DWELL somewhat to be more sure that the first recorded data will be good.

The calculation of the time required for an antenna to start delivering good data is based on on information in the station catalog. See the section on that catalog for details of the parameters mentioned here. The slew time is calculated based on the pointing direction at the previous and next sources along with the slew rates and accelerations for the antenna. An additional time TSETTLE is added to the slew time for the antenna to settle and the electronics to get ready. Additional time might be added for digital systems to set power levels based on TLEVSET for the first time a setup is seen (VLBA and VLA). The total time to be ready will not be less than MINSETUP, even if the slew is fast and the settling time (TSETTLE) is short.

The slew time calculator tries to take into account the need for cable wraps. The algorithm is simply — the shortest path to the next source will be taken even if that turns out not to be optimal later. Early VLBA experience suggested that a simple, predictable algorithm was preferred over a more optimal, but hard to predict, algorithm.

After the nominal times are determined, the recording start time is adjusted as described in the Adjusting the Scan or Recording Start Time section below using PRESTART, and MINPAUSE. Such adjustments were used to allow time for the recording media to get up to speed, formatters to reconfigure between scans with different setups, and for playback to synchronize on correlation. These were significant issues with the old tape systems, and to a lesser extent with the MARK5A system. The newer MARK5C recording system and DiFX correlators, and perhaps others, are able to record and correlate data beginning right at the assigned start time so such adjustments are not required.

The date specification for a scan is for the scan stop time, regardless of how the scan times are specified. If there is a scan that crosses midnight, this can cause some confusion, especially if it is the first scan of the experiment and the date is being specified along with START. If a schedule crosses a day boundary and START or STOP times are being specified, the new day should be specified. However, if midnight is crossed during any form of duration scheduling, the day will be incremented automatically.

All scans for a given station must be specified in time order. However, it is not necessary for scans for different stations to be in time order. This allows, for example, for the scans for one antenna to be specified separately from the scans for another antenna. While this works, it is not recommended because SCHED does not try to identify scans that can be correlated together. Anything that depends on knowing what the whole array is doing is likely to fail. DWELL time scheduling is one such item because SCHED must know how long the slews are for all antennas in a scan. Plotting of u-v coverage is another because SCHED only plots u-v points for baselines between antennas in the same scan. The estimates of data volumes and rates from the correlator, given in the summary file, are yet another because they depend on counts of baselines. Finally, any VEX file produced in such a way is likely to cause problems at a correlator that depends on it, such as DiFX (VLBA and many others).

SCHED allows sidereal time scheduling by means of the LST parameter. For VLBI, the concept of LST needs a bit more specification since it is different for each element of the array. LST can take an argument which is the station whose LST is to be used. If there is no argument, that station is assumed to be the VLA since LST scheduling was most commonly used for VLA schedules when the capability was first added to SCHED. Now that dynamic scheduling is being used on the VLBA, many users will want to set LST=VLBA_PT to conform to the style of scheduling requested for such projects.

If LST is specified, there are two ways to set the date. With the original method, the year and month are ignored and the day is assumed to be the (modified?) julian sidereal day number. Finding the LST day can be a bit painful, but a rough estimate can be had from the fact that LST day 60501 was 2006 Feb. 16. The estimate can be put in SCHED to narrow down to the right date. The second method is much easier and the scheme normally used. It is to specify the UT day in the usual manner. SCHED will attempt to figure out the LST day number, taking into account the fact that 0 hours LST is sometime in the middle of the UT day. It will also check if your start time is in the approximately 3.9 minutes where the result is ambiguous (LST days are shorter than UT days) and request specification of the LST day number — giving you the options.

If sidereal time scheduling is requested, most times and durations are assumed to be in sidereal units. Some exceptions are PRESCAN and MINPAUSE.

It is a very good idea, when using LST scheduling, to check the final output schedules, which are all in UT, to be sure that they are for the right day.

When dynamic scheduling, it is often difficult to mesh projects together perfectly. This can lead to gaps in scientific observing which causes an under-utilization of the array. SCHED supports two features that are meant to help with this situation. The first is that the user can specify optional scans on the ends of the project by setting PREEMPT = EXTRA for those scans. The scans will appear in the summary file so their properties are clear, but will not be passed to the machine readable files used to control the antennas. To activate them, so they are on the control files, parameter DOSCANS can be used to select the scan range to be used. The second option applies to 24 hour schedules which could be started at times other than in the original schedule and wrapped around the day. Parameter WRAP24 causes SCHED to copy the scans onto the end of the original scans to make a 48 hour schedule. DOSCANS is then used to select the desired 24 hour block. It is expected that DOSCANS and WRAP24 will be used mainly by operations personnel.

Dealing with Formatter Reconfigurations

NOTE: Concerns about formatter reconfigurations will disappear when the digital backends take over. About half of VLBA projects use the new system as of the start of 2013 and that should go to all during the year, so soon this section will be obsolete.

A factor to consider when planning scan times is legacy formatter reconfigurations. These happen when the internal switching and setup of the formatter at the station has to be changed. Such changes happen when any of a number of parameters, including the number of channels, the sample rate, the BBC assignments, the BBC sidebands, and the pulse cal detector setup, are modified. A formatter reconfiguration takes about 8 seconds on the VLBA and during that time the formatter is not sending valid time codes to the recorder. If this happens during recording, it knocks the correlator out of sync for both the duration of the reconfigure plus the time to resync. In practice, it also seemed to confuse the old VLBA hardware correlator somehow for maybe one or two stations and they can take over a minute to resync. This is not likely to be the case for the software correlator.

It is best to avoid reconfigurations if possible. In the rare cases where that is not possible, try to provide a gap between scans of sufficient length to do the reconfiguration. The formatter configuration requested during a gap is the same as that during the following scan, so this only requires using the GAP command (or any other mechanism for having one scan start a while after another ends). Common reasons that reconfigurations occur in schedules are changes in the sample rate, changes in the BBC sideband (remember for net upper sideband, the 20cm and 13cm systems on the VLBA use lower sideband at the BBC), and changes in the kHz part of the frequency which changes the pcal detector frequency (changes in the MHz part will not change the pcal setup and will not trigger a reconfigure).

Adjusting the Scan or Recording Start Time

The nominal scan start time, if set using DWELL, is the time good data is expected to be available. If recording and correlation could start instantly, that would also be a good time to start the recorders. The more modern systems, especially the Mark5C recorders and the software correlators, approach this ideal and the recordings are started at the time specified in the VEX file for the start of good data. That time is calculated based on the expected slew rates and on any extra time, specified using the TSETTLE, MINSETUP and TLEVSET parameters in the station catalog. The start can also be postponed with GAP or PRESCAN. With fixed scheduling (DUR, START, etc), the nominal scan starts are forced by SCHED , but the time of good data, if later than the scheduled scan start, is still set by the actual expected slews and additions and that is believed by the Mark5C control software and the correlator. Parameters MINPAUSE and PRESTART, discussed below have no actual effect if the derived start time is before the expected start of good data.

With older systems, including the MARK5A systems that are still in use at least part time at the beginning of 2013, it can take a small amount of time to get the the recording going at the stations and the correlation fully synced up. With previous generation correlators and tape recorders, this was a serious issue and it was advisable to start the recordings at least 20 seconds before good data. Modern (2010) correlators are faster so the total time needed for both starting recording and synchronizing is only a few seconds, or less. Another reason for possibly starting recordings early, or even recording continuously between scans is that the Mark5A disk system can only handle up to 1024 recording scans. A recording scan is the time between stops of the recording media. There might be several source scans in a recording scan. Fast-switching, phase-referencing observations with the older systems could run into this issue so the default MINPAUSE (see below) has been set to prevent recording gaps during the fast-switching in appropriate cases. This section describes the tools in SCHED to allow the recordings to be started early.

The schemes described in the scan times section (parent of this section) are used to set the times of the scans as reported in the output files meant for human consumption. But the telescope control files actually give the times for the recording to start and stop. For the legacy (Mark5A) systems, those times are in the crd.xx files for VLBA systems and as the uncommented scan-wide start time in the $SCHED section of the VEX file. For the RDBE (VLBA etc) and WIDAR (VLA) systems, it is the data good time in the VEX file, shown for each telescope as an offset from the start time.

There are two primary parameters that can affect the recording start time used for the legacy systems. They are PRESTART, and MINPAUSE. PRESTART is used to request that the recording be started the requested amount of time (record time) before the scan start time. If that time is earlier than the previous stop time, the recorder will be left running.

The extreme, and often useful, case of a pre-start is to not stop recording between scans. This is especially useful if you have many short scans with short intervals between them, such as when phase referencing. MINPAUSE sets the smallest gap between scans for which the recording will be stopped. If the gap is smaller, the recorder will be left running. MINPAUSE used to be in units of playback time, so it was multiplied by the speed up factor to get the effect at record time. The speedup factor is no longer a simple concept so that adjustment has been removed and now MINPAUSE applies to the record time.

The default value for PRESTART is 5 seconds when the DAR is the legacy VLBA system or the MKIV system. Otherwise it is zero, which will be the case with the modern digital systems. The default value for MINPAUSE is 10 seconds when using the Field System or the legacy VLBA DAR. Otherwise it is zero which is the case for the new VLBA digital system. The Field System with the DBBC may be switched to zero in the future.

PRESTART is applied before MINPAUSE. First the recording start time is shifted earlier, then the interval from the last stop time is examined to determine if the recording should be left running. The defaults of PRESTART=5, MINPAUSE=10 should be ok in most situations (they are also in a state of flux as of the end of 2010, so it is possible they have changed since this was written). Users should not need to worry about these parameters most of the time. The offset of the recording start time from the scan start time can be displayed in the summary file by adding PTSTART to the arguments of SUMITEM. The recording start time is also available in the sch. files.

Another way to shift the recording start time is to use the parameter PRESCAN. This parameter was the original way of introducing gaps between scans, but was considered obsolete in recent years. However, it may have a use as a way of increasing the time allowed between scans beyond what would be given with the station parameter TSETTLE, although a negative PRESTART can do the same thing. PRESCAN shifts the start time in either direction (positive shifts to later times) after the other parameters discussed above set the time. If a positive PRESCAN is given, and the DURation or DWELL is increased by the same amount, the whole scan can be shifted farther from the period of the slew, allowing somewhat increased confidence that the recording will start with good data.

2.2.3 Dynamic Scheduling

All of projects on the VLBA that do not involve other antennas or special constraints are scheduled dynamically. That means that they are put into a special queue, along with information about their minimum requirements, and then are run at an appropriate time given the weather and condition of the equipment. This increases the overall quality of VLBA output by avoiding observations at times when it is clear that the results will be poor, even if it also introduces inefficiencies in scheduling that mean that there is some idle time (projects don’t mesh together perfectly). For example, there is not much point in observing at 43 GHz when there is bad weather at many sites. But a 1.6 GHz observation at the same time might be fine. Dynamic scheduling also allows more flexible response to targets of opportunity. Galactic sources, in particular, tend to have short periods of enhanced activity so it is best to be able to observe when they are high. Of course, it is possible that some projects in the dynamic scheduling queue will never be scheduled.

The PI for a dynamically scheduled project will be given a window in LST at the VLBA_PT (Pie Town) that will be scheduled, if the observation is done. It is useful slotting projects together if the PI allows some flexibility in the actual start time. The PI should prepare a schedule using the LST parameter with Pie Town as an argument (LST=VLBA_PT).

When a program is selected for a dynamically scheduled time slot, VLBA operations personnel will modify the date (calendar or lst day number) to match the scheduled day. This last minute modification is necessary because the stations do not have an LST concept and the machine readable files delivered by SCHED must be in UT. The files will then be loaded to the sites with instructions about the time window to use, which may well be a subset of what is actually in the schedules. Because of this last minute modification of the date, it is best to minimize the use of dates in the SCHED input. Use durations instead.

To provide flexibility in the start time, it is useful to schedule using DWELL to set the scan lengths. Then SCHED can adjust the gaps between scans to allow for the slew times that will be experienced by the actual observations. If doing an astrometric project with “DELZN” segments (geodetic type observing all over the sky to solve for the zenith atmospheric delay), it is useful to use the ability of SCHED to construct such segments automatically. Since such segments depend on observing sources near rise and set, they cannot be moved around, so without the automatic construction of the segments, the start time cannot be changed.

2.2.4 Management of Data Recordings

For most VLBI observations, the data are recorded at the stations and played back later at the correlator. It is not yet possible for the recording process to be totally transparent to the user, but dealing with it is now much less of a burden than it was in the tape era. A top level issue is that a user is typically allocated a total amount of recording media that he/she is allowed to use. This number may be less than the total that could be recorded during the observation. It is required because the overall media supply may not be large enough to allow full time recording at the maximum bit rate and the scheduling committees need to apportion the resources according to the project needs and priorities.

Beyond the overall amount of data recorded, the disk-based systems still require the user to pay attention to the need for data quality checks, to maximum reasonable recording scan lengths, to the need for time at non-VLBA stations for module swaps, and to dealing with the fact that the correlatable data is not provided starting at the exact time specified for starting the recording. These topics are discussed in the Observing Strategy and Scan Times section and will not be discussed in detail here.

2.3 Recording Systems.

VLBI observations require the transmission of raw data samples over very long distances. Progress is being made toward an ultimate goal of doing this in real time over fiber networks. But EVLBI, as such a system is called, is still only used for a small portion of VLBI observing and that is not likely to change in some regions until more affordable access to high bandwidth networks can be obtained.

Most VLBI relies on recording the raw data on magnetic media, and then shipping that media to a correlator where it is processed days to months after the observations are made. Managing those recordings, and the specification of the data streams to be recorded, is a major part of scheduling with SCHED. This section provides background on the various recording systems in use.

Please be aware that recording systems are a technology under rapid development. It is entirely possible that some of the sections here are not entirely up to date.

2.3.1 Recording Systems History and Background

SCHED was originally written in about 1979 as the scheduling program for global VLBI observations using the Mark II recording system. That was a system capable of recording 4 Mbps on video tape recorders. It was in use in some parts of the world much longer than expected (at least to 2003), but is now gone as far as we know. SCHED version 9.4 and later does not support Mark II.

The wide band recording system in use for VLBI for many years was the Mark III system. SCHED was never a general purpose scheduling program for Mark III observations. Programs SKED and PC-SCHED served that role. However, SCHED was capable of scheduling Mark III observations on systems that used the VLBA control files (VLBA, VLA, and Green Bank). In fact, the output of SKED and PC-SCHED was normally processed through SCHED to produce the telescope control files for these antennas for all except geodetic projects. Mark III is also obsolete, although one Mark III schedule is still in the SCHED test suite. I am not aware of any Mark III systems remaining in use.

The Mark III system was replaced by several other systems with greater capabilities. These include the VLBA, VLBA4, Mark IV, S2, and K4 tape systems. There were correlators associated with each system, and there was a considerable amount of cross compatibility, either directly or through the use of translation machines. The Mark III, VLBA, VLBA4, and Mark IV systems all used the same tape transport, although with different electronics. In their native modes, they used different data formats, but the VLBA and Mark IV systems were capable of reading and writing Mark III data. More importantly, the VLBA and Mark IV systems have a wide range of compatible recording modes that could be correlated together on the VLBA, JIVE, and other correlators.

By 2007, the tape systems were replaced by disk based recording systems nearly everywhere. The early disk systems were plug compatible replacements for the tape drives so most of the data configuration remained unchanged.

The Mark5A system was the most widespread early disk system. It was developed by Haystack Observatory and the Conduant Corporation. As a plug replacement for the tape drives, the Mark5A system still has the concept of tracks.

The Mark5B system is an enhancement that uses the VSI standard interface to record the data channels without all the formatting baggage left over from the tape systems. The Mark5A+ system allows Mark5B recordings to be played on Mark5A playback units, but a minor glitch that nobody is in a position to fix is preventing its use on the VLBA. The Mark5B+ system uses a faster interface and can handle up to 2 Gbps.

The Mark5C system was being deployed in 2011 and is meant to record up to 4 Gbps, although it the initial configuration can be used at a maximum of 2 Gbps. The Mark5C- system is a scheme for allowing lesser Mark5 hardware to pretend to be a Mark5C system for system development.

As of early 2013, the VLBA winding down use of the Mark5A system and is moving most projects over to the Mark5C system. Some other observatories are also moving to Mark5C, but usually with different electronics.

There are other recording systems in use. The Japanese have a K5 system. The Australians are using a variant on the PCEVN system. Also a variety of groups are testing real time VLBI over the fiber networks. This can involve real time correlation, or recording at sites remote from the telescope.

Meanwhile, other potential future recording systems are being investigated.

2.3.2 Recording Systems Control

The profusion of recording systems described in the last section is further complicated by the the possibility of mixing elements of the different systems. There are three elements of each system that must be specified in order to make proper schedules. These are specified in the SCHED station catalog with the parameters CONTROL, DAR, RECORDER and DISK. The first element is the control system — what software (and hardware) is used to control the recording system. The options that SCHED can handle for wide band VLBI observations are VLBA and VEX. Formally, these actually refer to the control file type, although each type currently implies a specific computer and software system. Note that the CONTROL variable has other options, but they imply one of the above two, plus some specific other telescope control files.

The original VLBA control system runs on VME computers using software mainly written for the VLBA. A few other sites (VLA, Green Bank, and one of the systems at Effelsberg) have such systems to control their VLBI hardware. Systems controlled by the VLBA software always consist of VLBA data acquisition racks (DAR — BBCs, formatter etc) and Mark5 disks. During 2010, new Digital Backends (RDBE) and Mark5C recorders began to be introduced on the VLBA. These major changes are being used as an opportunity to upgrade the telescope control systems. The new system is based on the EVLA Executor control system and runs on a standard Linux computer. Information is passed to this system from SCHED via the VEX file. SCHED now writes VEX files for all observations as a result. The new control system will initially just control the new data acquisition system and recorder. A new C-band (6cm) receiver is under construction and it, along with all of the LO/IF switching will be placed under control of the new computer. Over the course of the next few years, all VLBA systems will be moved to the new control. In the meantime, both crd files for the old system and VEX files for the new system will be required.

The VEX option for CONTROL causes SCHED to generate a schedule file in the VEX format, as does the DOVEX main schedule input parameter (now the default). This is the schedule distribution file format developed mainly for the PC Field System (PCFS) and the Mark IV correlators. It is now used by the DiFX software correlator in use at the VLBA and other places, so it is now needed by most if not all projects. It also is needed to control all new hardware being installed on the VLBA.

The PCFS, running on Linux PCs, is used to control VLBA, VLBA4, Mark IV, S2, and MARK5 VLBI hardware at many non-VLBA stations including all of the EVN. It is the descendant of, and replacement for, the control system for Mark III systems. Sometimes this system is referred to as FS9, for “Field System 9”, referring to the earliest version that could handle VEX input.

Systems controlled by the PCFS can consist of a VLBA, VLBA4 or Mark IV DAR connected to a VLBA4, VLBA, Mark IV, S2, or Mark5 recorder. Each combination has slightly different capabilities and requirements. SCHED understands a considerable amount about what these capabilities and requirements are and attempts to insure that the requested observations are possible. However, when doing a large observation with many diverse telescopes, it is best to stick to standard, well tested, observing modes and use the frequencies selected using the setup file parameter BAND.

During the transitions between recording systems, it may not be obvious when the schedules are made which system a station will have. Or stations may have both and want to run observations on one or the other depending on the supply of media. Because of this situation, a separate input, called DISK can be specified in addition to RECORDER in the station catalog. It tells SCHED that the station has a disk system and schedules can be made for it. There is another new parameter, MEDIADEF, which can be TAPE or DISK, that can be used to set the default medium for the station while both are available. The MEDIA parameter in the TAPEINI section can be used to override the default. ¿From this description, it is clear that this scheme was designed for the transition from tape to disk which was finished a few years ago. As new varieties of disk or real-time systems are implemented, changes are likely.

2.3.3 MARK5 and EVLBI

The Mark5 disk-based system has replaced the various tape based VLBI recording systems. This system is a major advance on many fronts including scheduling. To a much greater degree than with previous tape systems, schedulers can ignore the recording system other than making sure that they are not scheduling to record more data than can fit on the disk space that they have been allocated.

SCHED supports Mark5 on the VLBA by including the required commands in the telescope control files (the crd files). For systems controlled by the Field System (PCFS), SCHED writes a .vex file in VEX format with the necessary commands to control Mark5. The Mark5A system is meant as a plug replacement for MarkIV or VLBA tape recorders. It still records the same tracks that would be recorded on a tape system so SCHED must still be aware of management of such issues. Such concerns will be less, or at least different, for more advanced versions of the disk based recording systems.

There are a few controls needed to schedule Mark5 natively. First, the station catalog must show that the station has a disk system. That is done with the DISK keyword. This is separate from the RECORDER keyword to allow a station entry to cover both tape and disk systems during the transition period. There is a station catalog keyword MEDIADEF that sets the default medium to use at each station. SCHED will use that default in the absence of an overriding MEDIA command in the TAPEINI section. Schedulers for most VLBA observations should probably ignore the problem and let operations deal with getting the recording system right by rerunning SCHED just before the observations. For EVN and Global sessions, it should be clear before the session which system will be used.

The examples egmk5vlba.key and egmk5vex.key show how to set up Mark5 observations. Now that the conversion to disk is complete all other examples have been, or will soon be, switched to disk.

SCHED supports VLBI over networks. This can involve real time correlation in which case the data are routed directly to the Network. An alternative might be called ftp VLBI. In this case, the data are recorded at the station, then read back through the Network, or alternatively, sent over the Network and recorded at the correlator, or both. There are a few parameters meant to help control eVLBI observation DATAPATH, GRABTO, GRABTIME, GRABGAP. This documentation needs to be updated more on how eVLBI is actually controlled. eVLBI is in regular use in Europe, but not on the VLBA, mainly because of differences in the availability of affordable network connections of adequate bandwidth.

2.3.4 VLBA

SCHED is the primary program for scheduling observations on the VLBA and other systems that use the VLBA control system. Not much will be said in this section about the VLBA systems because they are the “native” systems for SCHED and are discussed extensively elsewhere.

2.3.5 MARK IV (PCFS)

SCHED supports Mark IV observations on Mark IV (and VLBA4) antennas equipped with the Field System (PCFS). This is done by creating a *.vex file in the VEX format. The VEX file is a global and self-contained description of the experiment that is scheduled. The *.vex file can be read by the control system (PCFS) and translated (by a program called Drudg) into a list of commands for the telescope, data acquisition system and recorder.

SCHED produces VEX files with “adaptive” recorder control that enables continuous recording on PCFS controlled telescopes, but can only be correctly interpreted by FS9.3.11 (and higher). This aided the VLBA hardware correlator in synchronizing playback, but is no longer of much interest as the sync time with Mark5 disk systems and current correlators, including the DiFX software correlator on the VLBA, do not take more than a second to sync.

SCHED now writes VEX files by default. It can be prevented using the input parameter DOVEX.

Mark IV (MkIV) telescopes are characterized by DAR = MKIV in the station catalog and can only be requested to record in any of the MkIV FORMATs. Most MkIV telescopes only support specific BBC’s (called Video Converters) to be connected to certain IF distribution boxes. SCHED supports “astronomical patching” or a version of geodetic patching — see M4PATCH. The astronomical patching requires odd BBC’s to be connected to either IFCHAN = 1N (normal input, usually LCP) or IFCHAN = 1A (alternate, usually RCP). Even BBC’s have to be connected to IFCHAN = 2N (usually RCP) or IFCHAN = 2A for LCP. Also, you must use at least one of IFCHAN = 1N or IFCHAN = 2N (i.e. a schedule that uses both IFCHAN = 1A and IFCHAN = 2A is not permitted). This can be controlled by explicitly setting BBC. See the details about M4PATCH for the setup implied by the geodetic patching.

In December 2000 the capability to record 512 Mb/s was introduced. This is achieved by recording 64 tracks simultaneously on the tapes or Mark5A. It requires NHEADS = 2 in the station catalogue. All MkIV stations now record using the Mark5 disk-based system. MkIV Stations equipped with Mk5 systems can record data at up to 1 Gbps. This requires DISK = MARK5A in the station catalogue.

Several features are not yet available or supported for MkIV (and MarkIV based Mark5 systems). Some as of late 2004 (some updates in early 2008) are:

Continuous recording has been used widely, however the ability to acquire the information needed to flag data which is recorded during slewing is not universal (though is standard for EVN stations). The SCHED output .flg file can be used by the AIPS task UVFLG if telescope flagging data are not available. In addition users need to insert gaps during continuous recording whenever they want calibration data.

Phase Cal detection at the telescopes is not implemented. This will likely become available with the new digital backends. Also, DiFX is acquiring the ability to detect phase cal tones.

For MkIV (VLBA4) telescopes there is flexibility for controlling when Tsys measurements will be made. Tsys measurements will typically be made at the beginning of a scan if there is a gap in the recording. When scheduling long scans or continuous recording, one may need to insert gaps in order to obtain Tsys data.

In addition to requiring use of tested modes, SCHED will not allow speedup factor changes during mixed VLBA and Mark IV mode observations. This is because of track bit rate dependent delays that are different in the two formats. The correlator would require different clocks for different modes, which is not yet available. Fairly soon, this restriction will be relaxed. Again, MODETEST will turn off the test.

2.3.6 NON–VLBA Telescopes with VLBA Recorders

SCHED supports observations on telescopes that have VLBA recorders but are controlled through PCFS. This is also done by creating a *.vex file in the VEX format (see section on MkIV).

The telescopes are characterized by DAR = VLBA and RECORDER = VLBA, but CONTROL = VEX. They can have a flexible number of BBCs, and usually have only 2 IF channels: A & C. The telescopes can only be requested to record in any of the VLBA FORMATs.

In addition DAR = VLBA4 and RECORDER = VLBA4 systems have been introduced. These use the flexible VLBA data acquisition rack, but (DAR = VLBA4) have a Mark IV formatter mounted for recording up to 1Gb/s. Note that these systems write Mark IV formatted data and have been created to resemble Mark IV systems. In this sense their name is misleading. These systems required a RECORDER = VLBA4 in the tape era in order to accommodate 2 recording heads (optional), but now all Mark5A systems can record the requisite number of tracks.

Most of the VLBA racks controlled by the field system have what is known as the “geodetic wiring”. This means that not all of the BBCs can see all IFs. Also, there are not enough sampler inputs do use 2 bit samples from more than the first 8 BBCs. In fact, switching between lots of BBCs at one bit and 8 BBCs at 2 bits requires moving connectors that really weren’t designed to be moved often. This is an invitation for trouble. The IF restrictions are such that BBCs 1-8 can see IFs A and C while BBCs 1, 2, and 9-14 can see B and D. SCHED understands these restrictions in it’s automatic BBC assignment section. Note that, in some cases, the stations will put the same signals on IFs A and B and on C and D. This can be dealt with in the frequency catalog by giving B as the ALTIFN for A and D as the ALTIFN for C (or visa versa). Or, or course, you can specify IFCHAN explicitly in the setup file.

2.4 Wide Band Observing: RDBE, DBBC, VLBA and Mark IV Modes

This section covers the scheduling of wide bandwidth observations. With the older tape and MARK5A systems, that means 512 or 1024 Mbps using or using a large number of ”tracks” on disk. With the digital backends (RDBE and DBBC) and newer recording systems (MARK5C for now, maybe MARK6 later), completely new systems are involved. The first couple of paragraphs below are about the old systems. Then the section goes into more detail about the new digital systems.

OLD SYSTEMS:

With the Mark5A recording system, the maximum bit rate that can normally be recorded is 1024 Mbps on a Mark IV system and 512 Mbps on a VLBA system. These rates are recorded on a single module, unlike in the tape era when 2 drives or 2 heads were required.

SCHED can make schedules for the 512 Mbps and 1Gbps modes. See the examples eg512.key for a VLBA only case and eg2head.key for a PCFS (MarkIV) case. Since the advent of disk recordings, for the user, these modes are not much different from other modes. The VLBA telescope schedules indicate use of the wide band mode simply through the specification of track numbers above 64. Note that the two examples do either only VLBA or only Mark IV, but it is ok to mix them.

NEW SYSTEMS:

New digital backends and a new recording system started to be used for science in 2012. These increase the available bit rate to significantly higher values. The RDBE/Mark5C system developed at Haystack and NRAO records 2048 Mbps. Higher rates may eventually be provided. The DBBC system, developed in Italy and also using the Mark5B or Mark5C recording systems, is being deployed on a similar time scale and has similar bandwidths. Other, even wider bandwidth, recording systems are under development but will not be discussed here yet.

2.4.1 The RDBE system

The RDBE (Roach Digital Backend, where ROACH is the core board containing a large FPGA) is a module that takes in 2 analog IF signals, applies an anti-alias filter that passes 512 to 1024 MHz, sets the power levels, samples the signals at a 1024 MHz sample rate (8 bit samples at this stage), digitally filters the data to the final basebands, resamples the data to 2 bits, and formats it for recording. It takes the place of the IF distributers, baseband converters, samplers, and formatter (including pulse cal detectors) in the old VLBA system. The VLBA antennas have two RDBE systems each, allowing an increase in the number of channels, at least with the DDC personality (see below). In addition to allowing increased numbers of channels, the use of 2 RDBEs allows simultaneous access to all 4 VLBA IFs. That is useful for the S/X system and for the new 4-8 GHz system, for which two polarization pairs of output data are available.

Control of the RDBE and Mark5C recorders is handled by a new VLBA control system running on a standard Linux computer. The new system software is based on the EVLA Executor. Schedule information is given to this computer by way of the VEX file, which is converted by operations to a Python script that is read by the Executor. All new hardware installed at the VLBA for the next few years will use this control system and, probably slowly, the old hardware will be switched over to it. In the meantime, both crd files and VEX files are needed to control the VLBA sites. When the new 4-8 GHz receiver was installed on the VLBA, a new RF switch controller was installed that affects all observing bands. Because of this, both the new and old control systems must be used to support observations with either the new or old recording systems. Note that the VEX file is also used by field system stations (EVN and others) for antenna control.

The new control system at the site, and the DiFX correlator have a slightly different idea of when scans should start compared to the old systems. With the old system, the media are commanded to start at a time that is the same at all stations and is set as the nominal scan start time minus an offset given by PRESTART. The Vex file shows that time as the uncommented “start” time of the scan. But the Vex file also has a station dependent offset for the start of good data. With DWELL scheduling, that is usually zero. But if DURation scheduling is used, it can be significant. That time is often referred to as the good-data time or on-source time. It depends on SCHED’s concept of slew times and settling times. The new systems do not start the media, or the correlation until that time.

TERMINOLOGY:

Note that the terminology for the various signals has become rather confused. For backward compatibility in SCHED , we call the final analog signal sent to the sampler at 512-1024 MHz the “IF”. That is broken into narrower bandwidths called “subbands” by a polyphase filter regardless of RDBE personality. There is no flexibility to move those subbands around in frequency. The final signal that is resampled to, usually, 2 bits and recorded is called the “baseband channel” for purposes of SCHED. The baseband channel might be a subband (PFB personality) or might be further frequency shifted and filtered from within a subband (DDC personality). This terminology differs somewhat from EVLA practice where a baseband is the final analog signal and the final filtered signal is a subband.

RDBE PFB PERSONALITY:

The FPGA in the RDBE supports multiple personalities that can be swapped as needed. The first developed was the PFB personality that uses a polyphase filter to break each of the two 512 MHz IFs into 16 basebands of 32 MHz each, all lower sideband. Exactly 16 channels must be recorded, arbitrarily selected from the total of 32 provided from both inputs. This personality is selected by setting the DBE parameter to RDBE_PFB in the setup file. Of the 16 subbands of the polyphase filter from each IF, 15 provide good data. The other is really 16 MHz from each end of the 512 MHz, and is not useful. It is made available for selection in cases where it is desired to have all 16 required channels in one polarization. More typically, 8 channels, constituting polarization pairs, will be selected from each IF input. This personality can only provide 32 MHz basebands at fixed frequencies within the IF for a total of 2 Gbps. Other than selecting the desired subbands, there is no tuning flexibility. Note that the PFB personality cannot be used on both RDBEs at a VLBA station because the required VDIF output is not available and because the required 2 Gbps per RDBE is beyond the capacity of the recording system if both are used.

RDBE DDC PERSONALITY:

The second personality that is available is the DDC (Digital Down Converter). It is selected using the DBE parameter set to RDBE_DDC in the setup file. This personality provides up to 4 filters per RDBE and there are 2 RDBE units at each station. The filters can have frequencies that are multiples of 15.625 MHz (see below). The bandwidths of the DDC filters can be any factor of 2 step between 1 and 128 MHz.

There is a complication forced by the use of a polyphase filter first step of filtration to get the clock rate down to values the FPGA can support. Such filters do not have flexible frequency ranges. This one splits the band into 3 segments, 512 to 640 MHz, 640 to 896 MHz, and 896 to 1024 MHz. Each baseband must be confined to one of those ranges. The “crossover” frequencies at the filter edges have a range of something like 4-10 MHz (to be determined) that is not really usable. SCHED will issue a warning if an attempt is made to have a baseband cross one of these boundaries. Note that the polyphase filter to use will be determined by the frequency of the LO sum. It is possible that users of the 128 MHz bandwidth will want to offset slightly for better pulse cal performance and this will cause a tiny fraction of the band to get aliased. SCHED will issue warnings, but this can be tolerated.

The frequencies for the band edges in the DDC personality can be set to any multiple of 256(232) MHz = 0.0596046 Hz in principle. But values that are not integer Hz would cause problems elsewhere - mainly with returning to phase after changes. The smallest allowed value that qualifies is 15.625 kHz. One way to look at the allowed values is that they are N*125 kHz plus 0, 15.625, 31.250, 46.875, 62.500, 78.125, 93.750, or 109.375 kHz. If working with other antennas with legacy systems, it will be necessary to stick to multiples of 10 kHz which is only possible with the DDC by using multiples of 250 kHz. /schedb will warn if the frequency is not a multiple of 250 kHz and will abort if it is not a multiple of 15.625 kHz.

VLBA TUNING RESTRICTIONS:

The overall LO/IF/RDBE system on the VLBA will have some significant tuning flexibility issues. The RDBE is an add on to the older system where the baseband converters, which could take only a small portion of the 500 MHz IF, provided the necessary flexibility. The LO/IF system that creates those IFs is based on synthesizers that have set points at N*500+-100 MHz. Now, with the ability to take all of an IF, that restricted tuning ability will become an issue, especially in conjunction with the lack of tuning ability for the PFB personality and the crossover points for the DDC. Essentially all frequencies can be reached using more than one LO setting, so no cases have been identified where a particular spectral line cannot be observed. But full tuning flexibility that might be desired is not there. Eventually we hope to upgrade the front end synthesizers to designs with more tuning options, and in fact design and prototyping of such a system has started, although deployment is not yet funded (Feb 2012).

Note that, for the initial /schedb implementation of the RDBE, the code to provide default channel frequencies based on the band has not yet been written. It is necessary to give the frequencies in the setup file. See the simple examples. The defaulting capability will be added eventually. But for now, the upper-edge baseband frequencies with PFB personality must be from the following list: 1040.0, 1008.0, 976.0, 944.0, 912.0, 880.0, 848.0, 816.0, 784.0, 752.0, 720.0, 688.0, 656.0, 624.0, 592.0, 560.0. These can either be selected directly using the BBSYN setup file parameter, or values of FREQREF and FREQOFF can be selected so that the difference between the desired baseband frequency and the signed sum of all other LOs is one of these values.

EXAMPLES:

Example SCHED input (.key) files for observations using the new systems are:

egrdbe2.key which is a reasonably simple case with the VLBA and GBT.

manual_1.key shows a lot of SCHED inputs instead of taking the defaults. It uses the RDBE/DDC on the VLBA and WIDAR on the VLA1 (VLA1 not really offered yet, but VLA27 would be similar).

rdbepfb.key which is an even simpler case with just the VLBA and using a standard setup.

eg3mm_rd2.key which shows how to do referencing pointing at 3mm, including using narrow band data on masers, when the RDBE is used with the PFB personality. It uses the crd input parameters to control the VLBA legacy hardware which produces the power data used for reference pointing.

egddc.key which uses the DDC personality of the RDBE.

egddc2.key which uses the DDC personality with two RDBEs and 8 baseband channels.

egcwide.key which uses the PFB personality and observes using the new 4-8 GHz VLBA receiver with one dual polarization setup and one single polarization, widely split frequencies setup.

jvla.key is an example that uses the PFB personality of the RDBE for joint observations with the GBT and VLA. There are only 512 Mbps at the VLA in this mode.

vladdc.key is an example that uses the DDC personality with the VLBA, VLA, and GBT with a full 2 Gbps on all three.

hsaddc.key is an all-singing, all-dancing HSA example with the VLBA, VLA, GBT, and Effelsberg. It exercises reference pointing at all sites, array phasing at the VLA, and Doppler tracking.

pfbsettst.key is a vehicle for testing all the new RDBE/MARK5C standard setup files that use the pfb personality. These are the setups that start with rdbe_pfb.

n2227.key is a sample USNO Earth Orientation observation using PT and MK.

REFERENCE POINTING WITH THE RDBE:

See the Reference Pointing section for much more information on how to do reference pointing.

Reference pointing on the VLBA is handled by the legacy system using power measurements made by the old baseband converters (BBCs). When the main observations are using the RDBE, SCHED tries to set the BBCs as closely as possible to the settings of the RDBE baseband channels. For bandwidths below 16 MHz, this can be done well for 8 channels, as long as the requested frequency is below 1000 MHz in the IF. SCHED will select the center 8 channels if there are more from the RDBE (the PFB always gives 16). For wider bandwidth baseband channels, 16 MHz will be used and it will be centered on the RDBE channel. All this means that reference pointing, including using Doppler for setting frequencies and setting narrow bandwidths for masers can be done normally for the DDC personality. If such reference pointing must be done when using the PFB personality with it’s fixed 32 MHz baseband channels, it is best to set up the old system using the piggyback scheme as demonstrated in the example egrdbe.key. That requires separate runs of SCHED for the MARK5C and legacy systems.

PARALLEL MARK5A and MARK5C RECORDINGS:

Normally when scheduling a project that uses the RDBE/MARK5C system, SCHED creates control files for the old system (.crd files) that drive the telescope and other systems, but do not cause MARK5A recordings to be made. Since SCHED does not have adequate bookkeeping to allow independent specification of frequencies for both systems in one pass, a reasonable choice of frequencies and bandwidths for the old system is made based on the capabilities of that system and the settings for the new system.

During testing of the RDBE/MARK5C system, it is useful to have a parallel Mark5A recording. If the default choices of frequencies and bandwidths for the old system is adequate, SCHED can be told to make MARK5A recordings using parameter switch /htmlrefDOMKAMP:DOMKA. The only way to check what those settings are is to look at the output .crd files. Because of the limited bookkeeping, that information does not appear in the .sum file.

If the user does not want to take the Mark5A setups provided by SCHED with DOMKA, then the run can be set up as a piggyback with separate setups for each system. The scheme for doing was mentioned above, and is described and demonstrated in example egrdbe.key.

2.4.2 DBBC:

The DBBC in use at the EVN, LBA and many geodesy stations is also a system that samples at 512 or 1024 MHz and digitally filters the signals to the desired bandwidths. But it has a different design where, like with the old BBCs, the frequency can be set flexibly anywhere in the IF band without concern about crossover frequencies etc. The DBBC design has a module for each output baseband, so they are more directly comparable to BBCs. Support for the DDC personality of the DBBC has been implemented in SCHED. The PFB personality has only skeleton support and should be used with care.

The DDC personality is selected by default, and can be selected explicitly by setting the DBE parameter to DBBC_DDC in the setup file. SCHED will also accept a value of DBBC_PFB but this is not properly supported and will simply mimic the PFB personality of the RDBE (they are largely compatible). There are several different versions of the DBBC being deployed with slightly different components. The major difference is in the patching of IFs (aka conditioning modules) to particular BBCs (this may become fully switchable with future upgrades). Three variants are recognized by SCHED – ASTRO, GEO, HYBRID. The variant is specified in the stations file with the DBBCVER parameter. Each conditioning module (IF) has up to 4 switchable inputs. The signal available on each input is station dependent, so IF names (IFNAME, IFCHAN) should be assigned with due reference to the particular station’s wiring.

Support for the DBBC in SCHED is complicated by the multiplicity of versions, both in hardware configuration and firmware. There are up to 6 IF filters available, though only DBBC Version 3 (with the correct firmware) supports them all. The following table summarises the IF filters and which DBBC versions support them (this may require revision).


IF Filter # Frequency Availability



2 10-512 MHz All DBBC versions
1 512-1024 MHz All DBBC versions
4 1024-1536 MHzDBBC2 with upgraded firmware and DBBC3
6 10-1024 MHz DBBC3
3 1536-2048 MHz DBBC3
5 1150-1750 MHz DBBC3

Table 2.1: IF Filters available on the DBBC (version availabilities subject to confirmation!)

SCHED will permit a schedule that uses any of the 6 IF filters, but will warn if one of the less commonly available ones (i.e. 3, 5, or 6) is used.

Baseband filter widths of 1, 2, 4, 8, 16 or 32 MHz are possible. The 32 MHz mode is only available on later versions with the ‘e-series’ firmware upgrade and places additional constraints on which BBCs may be selected. These constraints are not understood by SCHED so normal defaulting mechanisms will fail - you will need to explicitly specify the BBC selection to use the 32 MHz filters.

The frequencies for the band edges in the DDC personality can be set to any multiple of 10 kHz. (There is also a binary tuning mode which allows band edges to be set to a multiple of 1024231 MHz = 0.476Hz, but its use is not advised and it is not currently supported by SCHED.)

Sampling is done with 2 bits at Nyquist rate only (1 bit sampling can be emulated by bitstream selection on the recorder, and SCHED will allow you to set nbits=1).

2.4.3 OTHER DIGITAL BACKENDS:

There is a variant on the RDBE being developed at Haystack for mm VLBI that has 4 input IFs and does not attempt any filtration. It simply samples and formats the data and sends it to the recorders. It can put out 8 Gbps. This device is not yet supported by SCHED.

When the DAR is the RDBE, the output channels and all the input channel information given to SCHED are written to the VEX file. But the crd files that control the old VLBA hardware also has to be told something. SCHED does not have a separate set of variables for all those configuration parameters, so it just does something reasonable. It sets the number of channels to the maximum of the number requested and 8. It sets the frequencies to cover the middle of the RDBE basebands and the sidebands to match the RDBE basebands. It sets the sample rate to the maximum of that requested and 32 Ms/s. It sets the channel bandwidth to the lesser of the request and 16 MHz. It only writes the first 4 pcal extraction requests (avoiding going into channel numbers that are too high). Recording on the Mark5A system is not requested.

2.5 Spectral Line Observations

SCHED can set observing frequencies for spectral line observations based on velocities provided in the source catalog and rest frequencies provided in a separate type of input. This option is invoked by specifying DOPPLER and can be turned off with NODOP (DOPCAL is an obsolete form that was too easy to confuse with “DO PCAL”). If DOPPLER is invoked, SCHED calculates the velocity of the center of the Earth with respect to the designated reference frame (VREF in the direction of the source at the time of the middle of the project. From this velocity, the source velocity from the source catalog, and the rest frequency, the required observing center frequency is calculated. The antennas need to know the LO settings so SCHED must know the bandwidth. The bandwidth will usually be obtained from the setup file. It may be provided for the scan with the BW parameter for some systems, unfortunately not including the new digital backends such as the RDBE on the VLBA.

The reference frames supported by SCHED are the “Local Standard of Rest” or LSR VREF=L, heliocentric VREF=H, and geocentric VREF=G.

Note that channels assigned to the same BBC will be given the same frequency as the first channel on that BBC, no matter what velocities etc are given for the other channels. This will be the case when there are upper/lower sideband pairs. Their frequencies cannot be set independently. Because of the different sidebands, they will, however, cover different velocity ranges.

The frequencies derived from the Doppler calculations have to be rounded off to a value that can be set on the available synthesizers. For the Mark III/IV and legacy VLBA systems, frequencies can be set to the nearest 10 kHz. For the RDBE with the DDC personality on the VLBA, usable frequencies are multiples of 15.625 kHz. Note that, if there is a mix of systems with 10 kHz and 15.625 kHz steps, one should round to 250 kHz because that is the lowest value common to both. Other systems are different — VSOP, for example, can only be set to the nearest 1 MHz. The RDBE with the PFB personality can only do frequencies in 32 MHz steps, and those have LO dependent offsets — it is probably best to avoid DOPPLER when using the PFB. The parameter DOPINCR can be used to control the rounding.

The Doppler calculations are for the center of the Earth for the middle of the project. This implies that the frequency for each source will be constant for the duration of the project. Experience over the years with spectral line VLBI has shown this to be the preferred observing mode since it minimizes the chances of mistakes at stations that do not have automatic frequency setting. The shifts of the resulting spectra of about a km per second that result from the rotation of the Earth can be removed in post-processing with the CVEL program in the NRAO spectral line software or with a task of the same name and with similar capability in AIPS.

The LO sum used when Doppler calculations are requested are calculated by either the radio definition (VDEF=R in the source catalog ) or the optical definition (VDEF=O or VDEF=Z). With the radio definition, the LO sum is calculated as RESTFREQ * (1 - v/c) - BW/2 where RESTFREQ is the line rest frequency from the line initialization input, c is the speed of light, and BW is the bandwidth (appropriately signed according to the sideband). With the optical definition, the LO sum is RESTFREQ / (1 + v/c) - BW/2. Typically velocities for radio spectral lines in galactic sources are given in the radio definition in the LSR frame. Extragalactic velocities, on the other hand, are typically in the optical definition in the heliocentric frame. The differences in the radio and optical definitions only matter at large (typically extragalactic) velocities.

SCHED will accept redshifts if VDEF=Z in place of velocities, but be very careful that you have adequate accuracy to calculate proper frequencies - the bandwidths are typically very much smaller than the observing frequency so the velocities must be accurate.

Internally, if Doppler calculation is requested, SCHED calculates the desired observing frequencies and puts them in the same array that would be used if FREQ were used. This will override any FREQ specifications in the main schedule and any frequency specifications in the setup files. The frequencies of baseband converters will then be set properly based on the FIRSTLO for the station. Please note that the setup files must still contain a complete, valid frequency specification. This is to allow validity checking and to allow SCHED to pick up default parameters from the frequency catalog. The frequency in the setup should be close enough to the desired observing frequency that only final tuning of the BBCs is needed to get the exact desired frequency. For the VLBA with its 500 MHz IFs, this is not a serious concern.

The number of channels desired is set with NCHAN in the setup file (NCHAN in the main schedule is an obsolete parameter and is not used.). To calculate a frequency, SCHED must have, for each channel, a bandwidth, a velocity from the source catalog, and a rest frequency from the line initialization input information. If a value is missing for any channel of any parameter, the value of that parameter for channel 1 will be used. This avoids the need, for example, of specifying lots of bandwidths when they are all the same.

For continuum sources mixed in with line sources, specify NODOP for that scan to avoid the Doppler calculations.

Often it is desired to observe a continuum source at the same frequency as a line source for bandpass calibration. This can be done by specifying the line source with DOPSRC in the continuum source’s scan. The DOPSRC will be used for the Doppler calculation.

The important parameters in the SCHED keyin file for Doppler frequency calculation are listed below. Detailed descriptions are given with the descriptions of other SCHED parameters.

DOPPLER and NODOP turn the Doppler calculations on and off.

DOPSRC is used to specify the source, if it is different from the scan source, for which the Doppler calculations should be made. This is useful for bandpass calibration. Warning - as with nearly all SCHED variables, it defaults to the previous scan. After using it, be sure to set it to blank or to the next source.

DOPINCR is used to determine the level of rounding of frequencies that is used.

LINENAME specifies which group of rest frequencies to use. It must match one of the sets of lines named with LINESET in the LINEINIT input.

BW sets the bandwidth for the scan and overrides the setup file value. This was useful for switching between wideband observations on calibrators and narrow band observations on line sources. The value in the setup file will be used if it is not specified. In general, it is a good idea to use a new setup file when changing bandwidths because quite a few other parameters also change. With the new digital back ends, oversampling is now allowed so BW basically doesn’t work.

LINEINIT indicates that after the next “/”, information on the rest frequencies of spectral lines will be given. If invoked, the rest frequencies will be read, and SCHED will return to reading input for the same scan that it was on before the “/”.

The rest frequencies are specified in separate keyin inputs in the SCHED keyin file following a “/” if LINEINIT was specified. There can be one rest frequency per channel, although any not specified default to the first which is often the desired behavior. There should be one velocity per channel in the source file for each source to be observed (other than continuum calibrators). Each group of lines has a name which is then referred to using LINENAME in the scan input. The group can change with each scan, but be careful to change the setup file, too, if necessary. Up to 10 groups of lines are allowed. The parameters in the LINEINIT group are:

LINESET:
Name of the group of lines. LINENAME in the scan input will be used to invoke this group.

Argument: Name of up to 8 characters.

Options: Any name.

Default: None

Usage: Defaults to previous value - don’t do it!

Example: LINESET=’H2O’

RESTFREQ:
Rest frequencies.

Argument: Up to one real number per channel. The first value will be used for any channels for which a value is not given.

Options: Any value.

Default: 0

Usage: Defaults to previous value.

Example: RESTFREQ=22235.08

ENDLINES:
This parameter, on a separate line with a “/”, ends the restfrequency inputs much like the ENDCAT parameter ends in-line source and station catalog inputs.

Argument: None.

Options: None.

Default: Not specified.

Usage: Defaults to previous value, but this has no effect since this will be the last line of the rest frequency input to be read.

Example: ENDLINES /

A fairly extensive list of possible rest frequencies is given below. These frequencies are not guaranteed. If anyone finds an error, please notify Craig Walker (cwalkernrao.edu).

---------------------------------------------------------------  
lineinit /  
!   Frequencies from Reid and Moran’s Annual Reviews article preprint.  
!   Do not keep more than 10 lines in a SCHED input file.  
lineset=’OH1612’  restfreq=1612.231   /  
lineset=’OH1665’  restfreq=1665.402   /  
lineset=’OH1667’  restfreq=1667.359   /  
lineset=’OH1720’  restfreq=1720.530   /  
lineset=’OH4660’  restfreq=4660.42    /  
lineset=’OH4765’  restfreq=4765.562   /  
lineset=’OH6030’  restfreq=6030.747   /  
lineset=’OH6035’  restfreq=6035.092   /  
lineset=’CH3OH’   restfreq=6668.5192  /  Breckenridge and Kukolich ApJ 438.  
lineset=’CH3OH’   restfreq=12178.597  /  Breckenridge and Kukolich ApJ 438.  
lineset=’OH13’    restfreq=13441.417  /  
lineset=’NH3’     restfreq=18499.393  /  Pratrap Preprint.  
lineset=’CH3OH’   restfreq=19967.3961 /  Menton preprint.  
lineset=’H2O’     restfreq=22235.08   /  
lineset=’CH3OH’   restfreq=23121.0242 /  Menton preprint.  
lineset=’CH3OH’   restfreq=25124.87   /  
lineset=’SiO425’  restfreq=42519.3    /  
lineset=’SiO428’  restfreq=42820.54   /  
lineset=’SiO431’  restfreq=43122.03   /  
lineset=’SiO862’  restfreq=86243.35   /  
lineset=’SiO868’  restfreq=86846.89   /  
lineset=’CH3OH’   restfreq=44069.43   /  Bachiller preprint (SAO)  
lineset=’CH3OH’   restfreq=97980.97   /  Plambeck preprint (SAO)  
lineset=’SiO1293’ restfreq=129363.26  /  
! some more from VLA OBSERVE  
lineset=’H’        restfreq=1420.405752   /  
lineset=’H2CO4830’ restfreq=4829.656900   /  
lineset=’H2CO145’  restfreq=14488.475000  /  
lineset=’NH3(1,1)’ restfreq=23694.495500  /  
lineset=’NH3(2,2)’ restfreq=23722.633600  /  
lineset=’NH3(3,3)’ restfreq=23870.129600  /  
lineset=’NH3(4,4)’ restfreq=24139.416900  /  
lineset=’NH3(5,5)’ restfreq=24532.988700  /  
endlines /  
-----------------------------------------------------------------

The example below shows the SCHED input for a spectral line It is a modified version of the file used for a project by Phil Diamond in Dec 95. The modifications are to adjust for some of the new features of SCHED that were not available at the time the file was used. Note that it is not necessary to repeat the DUR and GAP specification every scan. However some users prefer to show these details and it certainly doesn’t hurt. Also, the bandwidth specification is the same as the setup file so it is not required (it used to be).

! EXAMPLE - spectral line observations.  
overwrite  
 
! Note added Jan. 17, 2013 - GBT needs pointing which isn’t shown here.  
 
 
! Nov. 1, 2012.  Use GBT instead of VLA which can no longer  
! use the legacy system.  Eventually switch to RDBE/DDC and WIDAR.  
! Also switch to 2 bit and removed tpmode.  RCW.  
! ==========================================================  
! =================  Cover Information  ====================  
! ==========================================================  
 
EXPT = ’BD27 VLBA format 7mm line 1995 DEC 29 18:00 -> DEC 30 18:00 UT’  
EXPCODE  = ’BD027’  
VERSION  = 1  
 
PINAME   = ’P.J.Diamond’  
ADDRESS1 = ’NRAO’  
ADDRESS2 = ’P.O. Box O’  
ADDRESS3 = ’Socorro, NM 87801, USA’  
PHONE    = ’1-505-835-7365 (work) or 1-505-835-2095 (home)’  
OBSPHONE = ’1-505-835-7365 (work) or 1-505-835-2095 (home)’  
FAX      = ’1-505-835-7027’  
EMAIL    = ’pdiamond@nrao.edu (internet)’  
OBSMODE  = ’VLBA’  
OBSTYPE  = ’VLBA’  
 
! ==========================================================  
! ==============  Correlator Information  ==================  
! ==========================================================  
 
correl   = ’Socorro’  
coravg   = 4  
corchan  = 256  
cornant  = 10  
corpol   = ’off’  
corwtfn  = ’uniform’  
corsrcs  = ’standard’  
cortape  = FTP  
corship1 = ’Athol Kemball’  
corship2 = ’P. O. Box O’  
corship3 = ’Socorro NM 87801’  
 
! ==========================================================  
! ====================  Source Catalog  ====================  
! ==========================================================  
!  This has sources with positions in mixed equinoxes.  
!  It is normally recommended to use J2000.  
!  Note most of the continuum sources below could be picked up  
!  from $SCHED/catalogs/sources.gsfc  
 
SRCCAT /  
SOURCE=’3C273’    RA=12:26:33.2480 DEC= 02:19:43.290 EQUINOX=’B1950’ /  
SOURCE=’3C279’    RA=12:53:35.8380 DEC=-05:31:08.040 EQUINOX=’B1950’ /  
SOURCE=’3C345’    RA=16:41:17.6080 DEC= 39:54:10.820 EQUINOX=’B1950’ /  
SOURCE=’3C454.3’  RA=22:51:29.52   DEC= 15:52:54.35  EQUINOX=’B1950’ /  
SOURCE=’OJ287’    RA=08:51:57.2530 DEC= 20:17:58.440 EQUINOX=’B1950’ /  
SOURCE=’1823+568’ RA=18:23:14.9490 DEC= 56:49:18.050 EQUINOX=’B1950’ /  
SOURCE=’1334-127’ RA=13:34:59.8150 DEC=-12:42:09.900 EQUINOX=’B1950’ /  
SOURCE=’1633+382’ RA=16:33:30.6280 DEC= 38:14:10.050 EQUINOX=’B1950’ /  
SOURCE=’0420-014’ RA=04:20:43.5400 DEC=-01:27:28.660 EQUINOX=’B1950’ /  
SOURCE=’1749+096’ RA=17:51:32.8185 DEC= 09:39:00.728 EQUINOX=’J2000’ /  
SOURCE=’RAQR’     RA=23:41:14.269  DEC=-15:33:42.89   EQUINOX=’B1950’  
                  VEL = -27.0, -27.0 /  
SOURCE=’RLEO’     RA=09:44:52.2    DEC= 11:39:40.8   EQUINOX=’B1950’  
                  VEL = -2.0,  -2.0 /  
SOURCE=’VYCMA’    RA=07:20:54.6    DEC=-25:40:12.2   EQUINOX=’B1950’  
                  VEL = 20.0 /  
SOURCE=’VXSGR’    RA=18:05:02.9    DEC=-22:13:55.6   EQUINOX=’B1950’  
                  VEL = 8.0 /  
SOURCE=’UHER’     RA=16:23:35.0    DEC= 19:00:18.0   EQUINOX=’B1950’  
                  VEL = -15.0, -15.0 /  
SOURCE=’IKTAU’    RA=03:50:43.7    DEC= 11:15:31.8   EQUINOX=’B1950’  
                  VEL = 34.0, 34.0  /  
SOURCE=’TXCAM’    RA=04:56:41.4    DEC= 56:06:29.9   EQUINOX=’B1950’  
                  VEL = 9.0, 9.0 /  
SOURCE=’NMLCYG’   RA=20:46:25.59   DEC= 40:06:58.3   EQUINOX=’J2000’  
                  VEL = -5.0, -5.0 /  
SOURCE=’SPER’     RA=02:19:15.1    DEC=+58:21:34.0   EQUINOX=’B1950’  
                  VEL = -40.0, -40.0 /  
 
ENDCAT /  
 
! ==========================================================  
! ====================  Station Catalog  ===================  
! ==========================================================  
 
stafile  = ’$SCHED/catalogs/stations.dat’  
freqfile = ’$SCHED/catalogs/freq.dat’  
 
! ==========================================================  
! ==============  Spectral line rest frequecies  ===========  
! ==========================================================  
 
LINEINIT /  
lineset=’ccal’  restfreq=43122.027, 43122.027, 43126.027, 43126.027,  
                         43130.027, 43130.027, 43134.027, 43134.027 /  
lineset=’prog’  restfreq=43122.027, 43122.027 /  
ENDLINES /  
 
! ==========================================================  
! ====================  Observing setup  ===================  
! ==========================================================  
!  This is a fairly fully specified setup file.  
!  Note the VLBA and GBT setsups are the same in this case.  
 
setinit = bd27.set  /  
nchan    = 8  samprate = 8.0  bits = 2  bbfilter = 4.0  !  128 Mbps  
format = VLBA1:1  
bbc      = 1, 2, 3, 4, 5, 6, 7, 8  
netside  = U, U, U, U, U, U, U, U  
ifchan   = R, L, R, L, R, L, R, L  
!    Radio Astronomy allocation:  42400-43500  
pcal     = ’off’  
freqref  = 43150.99  
freqoff  = -8,-8,-4,-4,0,0,4,4  
firstlo  = 42400.00  fe(1) = ’7mm’   fe(3) = ’7mm’  
synth(2) = 7.6  synth(3)= 11.6   ! LO = Syn(2) + 3*Syn(3)  
station  = ’VLBA’, ’GBT_VLBA’   rchan = A  lchan = C   /  
/  
endset /  
 
!  As a demonstration, the following is all that is needed  
!  to get an equivalent setup to the above.  It is  
!  the same.  Note that both turn off the pulse calibration tones  
!  which can mess up spectral line observations.  
 
!  Neither setup uses the default ’format’ because that would give a  
!  speedup factor on correlation and the correlator output data  
!  rate would be too high.  Note that the format can be forced  
!  with either ’tpmode’ or ’format’.  
 
setinit = bd27a.set  /  
nchan    = 8  bits = 2  bbfilter = 4.0  
pol      = dual  
pcal     = ’off’  
band     = ’7mm’  
/  
endset /  
 
! ==========================================================  
! =================  Initial Scan Information  =============  
! ==========================================================  
!  
STATIONS = VLBA_SC, VLBA_HN, VLBA_NL, VLBA_FD, VLBA_LA,  
           VLBA_PT, VLBA_KP, VLBA_OV, VLBA_BR, VLBA_MK, GBT_VLBA  
 
YEAR   = 1995  
MONTH  = 12  
DAY    = 29  
START  = 18:02:00  
!  
!  
LINENAME = ’ccal’  DOPPLER  
 
! ==========================================================  
! ========================  The Scans  =====================  
! ==========================================================  
SETUP  = ’bd27a.set’  
SOURCE = ’1749+096’  GAP = 00:02:00 DUR = 00:11:00 DOPSRC ’SPER’/  
!  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
!  
SETUP  = ’bd27.set’   !  Try the other one.  
SOURCE = ’3C454.3’   GAP = 00:02:00 DUR = 00:11:00 DOPSRC ’SPER’/  
!  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
!  
SOURCE = ’3C454.3’   GAP = 00:02:00 DUR = 00:11:00 DOPSRC ’SPER’/  
!  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’SPER’      GAP = 00:02:00 DUR = 00:11:00 /  
!  
!     __________________________________  
!    |                                  |  
!    |   Many scans in the same style.  |  
!    |__________________________________|  
!  
 
SOURCE = ’1749+096’   GAP = 00:02:00 DUR = 00:11:00 DOPSRC ’UHER’/  
!  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
!  
SOURCE = ’1749+096’   GAP = 00:02:00 DUR = 00:11:00 DOPSRC ’UHER’/  
!  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
SOURCE = ’UHER’       GAP = 00:02:00 DUR = 00:11:00 /  
!  
SOURCE = ’1749+096’   GAP = 00:02:00 DUR = 00:11:00  DOPSRC ’UHER’/  
! ---------------------------------------------------------------------

2.6 Reference Pointing

At high observing frequencies, it can be difficult to point antennas with sufficient accuracy to keep the target source in the beam. One tactic to improve this situation is known as reference pointing. The idea is to peak up the pointing on a source prior to the VLBI scan. The source can be the target source, if it is sufficiently strong. Otherwise it can be another source. It is best to find a source as close as possible to the target, but it may be necessary to go tens of degrees to find one that is suitable. The reference pointing is commonly done at a lower frequency than the interferometer observations for improved SNR.

Reference pointing is commonly used at the VLBA for observations at 3mm. The actual pointing observations are typically done at 7mm where the sensitivity is greater and the beam is larger. The pointing offsets are determined by the on-line system by fitting total power measurements made while the antenna is moved over a pattern that includes the nominal on-source, half power, and off-source positions. Often this is done on strong SiO maser sources. One minute should be allowed for completion of this pattern after the antenna reaches the pointing source. Once a pointing offset has been determined, it will be used until another is determined, or the project changes. It cannot be turned off. Optimal time intervals between pointing scans and maximum offsets to pointing sources are not yet known. But pointing every half hour to hour on sources within about 20 degrees should be ok.

The power data used for the reference pointing is measured by the legacy system baseband converters (BBCs) which should be kept in mind when scheduling MARK5C/RDBE observations. More on that later.

Because total power mode is being used for VLBA pointing, sources must be very strong — more than about 10 Jy for continuum sources or about the same flux density averaged over the observing bandwidth for line sources (peak Ta of about 2 K). Very few continuum sources are strong enough, so most appropriate sources are SiO masers observed with restricted bandwidth, usually 2 MHz, centered on the line. See the sample pointing command file $SCHED/catalogs/peak.cmd, provided with the SCHED catalogs and discussed below, for a list of possible targets. Most of the SiO line sources are variable. The ones in peak.cmd were thought to be good at the time the file was made. Information on masers used to be found at the SEST web site. That link is now dead. Please let me know if you know an alternative. For information on high frequency flux densities of continuum calibrators, one can try the CalFind tool at the CARMA website. Please recommend other options if you have them.

On the VLA reference pointing must be used for observations utilizing frequencies greater than 15 GHz. Reference pointing needs 2.5 minutes on source to get solutions. See the discussion of VLAPEAK and the comments in the example hsaddc.key for more details. Please see the VLA’s high frequency strategy guide for more details. For more information on VLBI at the VLA, see VLBI at the VLA guide.

For the GBT, reference pointing is recommend for frequencies of 8 GHz and higher. The interval should be 4-5 hr for 8-10 GHz, 3-4 hr for 12-16 GHz, 1.5-2 hr for 18-26 GHz, and 30-45min for 40-50 GHz. The pointing source should be stronger than 0.5 Jy and within 15 degrees of the target. Allow 8 minutes or more in a non-recording scan for the pointing. For more on VLBI at the GBT, see the GBT documentation.

For Effelsberg, reference pointing should be used for frequencies above 5 GHz. Like the GBT, allow 8 minutes on-source.

Reference pointing scans can be inserted explicitly by the observer or SCHED can be requested to attempt to do the job automatically. For explicit scan insertion, the user specifies a scan with times and a source. Other factors such as the setup can also be specified. The parameters PEAK and/or VLAPEAK will need to be set and the user should consult the documentation on those parameters. SCHED can be requested to fill most of the required parameters using the same information used for the automatic scan insertion discussed below. See the discussion of the parameter POINT for information on how to control this semi-automatic mode.

Note that for the VLBA is in a transition period between the legacy control system and a new control system similar to that on the VLA. During the transition, both systems are operating in parallel. They cannot talk to each other, but are run from crd files (legacy) and a vex file (new system) written by SCHED for the same schedule. For a project using the RDBE and MARK5C, the channel control information must be appropriate for those devices. But the antenna control is still in the hands of the legacy system for all cases, and reference pointing is based on power measurements made in the legacy baseband converters. SCHED sets the legacy system frequencies and bandwidths to match as well as possible those being used in the RDBE. For continuum sources, this is ok for reference pointing. But most reference pointing is done on SiO masers using narrow bandwidths and with frequencies set using Doppler calculations. With the DDC personality, that is also ok because narrow bandwidths at flexible frequencies can be set, and be matched between systems.

For RDBE based observations using the PFB personality, reference pointing becomes a problem. The PFB can only use 32 MHz bandwidths at very restricted frequency set points. A scheme has been established using the input parameters CRDFREQ, CRDDOP, CRDBW, CRDCH1, CRDSETCH, and CRDNCH to allow somewhat independent control of the legacy BBCs. See the descriptions of those parameters, and the example eg3mm_rd2.key for details. As shown in the example, these parameters can be used for both explicit pointing scan insertion and for use with automatic pointing scan insertion by SCHED. Note that these capabilities have replaced the need that existed when the RDBEs were first deployed for separate MARK5A and MARK5C schedules.

Explicit insertion of pointing scans can be a pain and can completely dominate the work involved in scheduling high frequency observations. Therefore SCHED has a mode where it can do the work. This mode is invoked with the AUTOPEAK command and involves the use of a special set of input parameters either from a separate file, the PEAKFILE, or from in-stream commands, in the main SCHED input, contained between PEAKINIT and ENDPEAK. Three standard versions of this file are peak.cmd (VLBA legacy system), peak_RDBE_DDC.cmd (use with the RDBE using the DDC personality), and peak_RDBE_PFB.cmd (use with the RDBE using the PFB personality). The three files differ only in the setup files they specify and are, in fact, constructed from the same master file. The standard files can be used as examples of the format. It is possible to watch details of the process by which SCHED chooses pointing sources by setting the parameter PKWATCH. Be warned that this can produce a lot of output to the sched.runlog file.

There are several examples that demonstrate the use of reference pointing. The best example for the new systems (RDBE/DDC, WIDAR etc) is hsaddc.key. That example demonstrates reference pointing at the VLBA, VLA, GBT, and Effelsberg, array phasing at the VLA, and Doppler setting with the DDC personality. As noted earlier, eg3mm_rd2.key demonstrates the use of the crd parameters to schedule reference pointing when using the RDBE with the PFB personality. For reference pointing on the VLBA using the MARK5A systems, see the “eg3mm” examples. eg3mma.key sets up the pointing scans without any help from the automatic features in SCHED. eg3mmb.key demonstrates use of the external peak command file. eg3mmc.key produces the same results but using PEAKINIT and no external file. These examples only include a few VLBA stations. For the new systems, they are mostly superceded by eg3mm_rd2.key.

The peaking control information is organized around groups of antennas and lists of possible pointing sources. Up to 5 groups of antennas can be specified. For full automatic pointing, separate scans will be added for each group (this can add quite a few scans). For each group, SCHED finds the source in the pointing list that can be reached most quickly from the target source, that is above a specified minimum elevation at all antennas in the group. Pointing will only be added for scans observing at a frequency above a specified cutoff and only when there is enough of a gap in the schedule to fit one or two scans plus the slew to the pointing source from the previous VLBI source and the slew to the next VLBI source. The parameter GAP can be used to create such a gap. See the discussion of that parameter for a few more details.

The input parameters for the PEAKFILE are:

SRCFILE specifies the file name for a file containing pointing sources. That file is in the same format as the main source catalog and, indeed, is appended to the source catalog in the internal files in SCHED. The default is $SCHED/catalogs/sources.pointing which is a file provided with the SCHED distribution. If you don’t wish that any file is read (ie the pointing sources are in the main source catalog), specify NONE. This parameter can only be specified once, or rather the last value specified for all groups is used.

SETUP specifies the setup file to use for this group for pointing with continuum or very strong line sources. These are sources for which CALCODE is not ’L’. If SETUP is not specified, it keeps the value set in the previous group. The initial default is blank, which will probably produce an error.

SETUPL specifies the setup file to use for this group for pointing on spectral line sources with CALCODE = ’L’. The setup should be one with a 2 MHz bandwidth specified. If not specified, it keep uses the value of SETUP.

LINEINIT has exactly the same effect as the main program input LINEINIT and is used to delimit input of spectral line rest frequencies. This allows the frequencies to be specified in the PEAKFILE rather than the main program. It is allowed to have LINEINIT sections in both the main program and the PEAKFILE.

MINFREQ is the minimum frequency (MHz) for which attempts will be made to insert pointing scans. The default is 60000 MHz which is appropriate for the VLBA. This parameter keeps the value of the previous group if not specified.

MINEL is the minimum elevation allowed for a pointing scan. Higher elevation scans will give better results, but to high a MINEL may cause SCHEDto have to choose a pointing source that is far away.

DWELL is the minimum integration time to use for a pointing scan. For the VLBA, the default of 60 seconds is appropriate. For the VLA, it should at least 2.5 minutes. See the discussion of the schedule parameter VLAPEAK for much more information. DWELL keeps the value set for the previous group if not set.

STATIONS is used to specify the stations for the group. As of this writing, the maximum number is 30, which is also the maximum number of stations in a schedule. Stations in a group will share a pointing scan while a separate scan, potentially with a separate reference source, will be used for stations in another group. It is appropriate to keep stations at each end of the array in separate groups because the appropriate reference source may vary near the time of rise or set of the target source.

LINENAME specifies which spectral line to use in a reference pointing scan. It has the same meaning as the main schedule parameter LINENAME. It defaults to blank which is probably not what you want. It keep the same value as the previous group if not set.

VLAMODE specifies the main schedule parameter VLAMODE to use for the pointing scans involving the VLA. See the descriptions of that parameter and of VLAPEAK for details.

ENDPEAK is used to terminate peak command input in the main SCHED control file. It should be in a group of its own since no other parameters specified with it will be parsed.

As with all types of SCHED input, end each group with a “/”. The order of parameters within a group (between “/”s) is not significant.

2.7 Multiple Phase Centers

The DiFX correlator has a capability to process many phase centers within a primary beam in one pass. It does this by cross correlating with high spectral resolution and short time integration, then splitting the data paths out for each desired phase center, shifting the delay and phase for the new center, and integrating in time and frequency. There is a price of about a factor of 2.5 to do the large transforms involved, but there is very little additional burden for each phase center. The difference in processing time between 20 phase centers and 200 is about 20%. Up to about 500 phase centers in a field have been tested. This mode is expected to be popular for surveys and for in-beam calibration at lower frequencies.

SCHED supports the multiple phase center mode by providing the details of all the desired phase centers to use for a given pointing center in the output .v2d file, which is used in correlator setup. In the future, this information could also go to the VEX file when the standard and the readers can receive the information.

To invoke multiple phase center processing, and specify the centers, the user should provide a list of all the sources to use with each pointing center. To do this a PCENTERS section should be added to the main SCHED input file. Within that section, each group of centers is given a name and a list of source names. The sources need to correspond to sources in the source catalogs. It is likely that the user would create a catalog of the offset pointing centers and invoke it, along with the standard catalog, using the new ability to use two source catalogs using SRCFILE and SRCFILE2.

To tell SCHED to use one of the named lists of pointing centers, specify the name of the group from PCENTERS using the input CENTERS for each scan. For now, the same list must be used for all scans on a pointing center and all scans on that pointing center must use the list. The internal structure of SCHED will allow that one-to-one correspondence between pointing centers and phase center lists to be relaxed if and when the information can be transmitted to the correlator.

When using this capability, the user should specify the size of the FFTs to do on each baseband channel before splitting the data for each phase center. This is done with the (new) second argument to SCHED input parameter CORCHAN. Normally that argument can be ignored and the FFT size will be set to the larger of 128 or the first argument. The FFT size needs to be large enough that there is is insignificant delay smearing in a single channel. The required size depends on the baseband bandwidth (B MHz) and the maximum distance between the pointing and phase centers (x arcsec). For the VLBA for a 5% loss of amplitude on an offset source, the number of channels should be near B*x/2.35. A somewhat more conservative criterion is to limit phase winding to 5 spectral points per turn of phase in the spectrum. By that, given that the maximum delay change for a 1 arcsecond shift is 139 ns on the longest VLBA baseline (8600 km), the number of channels should be near 5*0.139*B*x. The full width, half maximum beamwidth of a VLBA antenna (25m) is very close to 30 and 1 arcminutes at 1.4 and 43 GHz, respectively. For the 1.4 GHz case, the above two criteria give 3063 and 5004 channels for a 4 MHz baseband channel width. A specification of 4096 channels would likely be reasonable. With the RDBE, much wider baseband channels are possible requiring many more spectral channels.

See the Wide-Field Imaging section of the Observational Status Summary for more information on delay and fringe rate smearing.

There is an example, egcent.key, with an associated catalog egcentsrc.dat, with the SCHED examples to demonstrate the use of this mode.

2.8 Automatic Insertion of Geodetic Segments

Phase referencing for weak source detection and astrometry depends on the ability to transfer interferometer phase from a calibrator to a target. The largest source of error in that transfer is the atmosphere. The ionospheric component of the atmosphere can be calibrated using multiple observing bands or modeled with the help of GPS based ionospheric models. The non-dispersive tropospheric component needs to be calibrated, either by measuring gradients using multiple calibrators near the target, or deriving the zenith delay from observations and using a mapping function to get the elevation dependence. The latter method is generally accomplished by inserting occasional clusters of observations of calibrators around the sky from which the clock offset and the zenith delay can be derived. AIPS task DELZN is typically used to make the solutions, although some users have their own programs for the purpose. These clusters of calibrator observations are called geodetic segments or DELZN segments.

Constructing a geodetic segment can be tedious given that one wants low elevation observations at all stations. The tropospheric effect scales roughly as secant(zenith angle) (hereafter SecZ). The elevations at each VLBI station are different and change rapidly with time. It is also best to have sources that are high at some stations and low at others to give robust SecZ fits. External programs have been written to construct geodetic segments for insertion into SCHED and libraries of segments are available, mostly from Mark Reid of CfA. But any schedule with such segments is tightly constrained in time — any time shift will cause what were low elevation scans to become either high elevation scans or scans where the source is down. Plus gathering the required segments can be tedious.

/schedb can build and insert geodetic segments automatically into schedules. This should drastically reduce the overhead in constructing such segments, and allows such segments to be made easily when the station list is not just the VLBA. Also the schedule can be time shifted easily, a possible benefit for dynamic scheduling. When there is a time shift, a different list of sources for each segment, optimized for the new time, will be built. It has also been found that this capability can be used to make short groups of scans that can be used for atmospheric opacity solutions by AIPS task APCAL.

To request that a geodetic segment be built, the user should specify a scan with the parameter GEOSEG given with an argument that is the total duration of the segment (typical values are 20 to 45 minutes). A list of sources from the normal SCHED catalogs to consider for the geodetic segments is given with the input parameter GEOSRCS. Other parameters to consider to influence the source selection are DWELL (the length of the individual scans within the segment), OPMINEL (the minimum elevation to consider — 10 degrees is a reasonable choice), OPMINANT (the minimum number of stations in a scan) and SETUP (the setup file — typically one with a wide spanned bandwidth and maybe not at the same band as the main observations). Be sure to set these parameters back to their desired values for the main observations (GEOSEG will revert to zero by default) or you may get unexpected behavior. In addition, for the scan that is being turned into a geodetic segment a source needs to be specified. It will be ignored in constructing the segments, but without it some of the SCHED checking that comes earlier will not be happy.

The parameter GEOPRT can be used to cause some details about each trial source sequence tested to be printed to sched.runlog. There are various levels of print possible.

The algorithm used to construct geo segments is described in more detail below. It involves constructing a number of trial segments and selecting the best. There are a number of control knobs sticking out that the user might want to play with although the defaults are reasonable. The parameter GEOTRIES controls the number of trial segments to test. Setting GEOTRIES large will likely produce a slightly better solution at the cost of high run times for SCHED. The algorithm for picking sources is reasonably good so the best of the early tested segments is likely to be nearly as good as anything found later. The source picking algorithm is based on fits for secZ, with a penalty for long slews. It is also capable of leaving an antenna out of a scan if it gets to source much later than other antennas. If that source would have been important for the slow antenna (low elevation), it is blocked so that it can be used in a later scan. The standard is that an antenna will be left out of the scan, or the source blocked, if that antenna gets to source more than GEOSLOW (default 40 seconds) later than the third to last antenna to get there. The choice of the third-to-last antenna for the reference was an effort to deal with various awkward scenarios that can arise when not all antennas are in all scans.

There is an example among the SCHED examples called egdelzn.key that shows how to construct a file with automatic geodetic segment insertion. The GEOSRCS in that example are the set provided by Mark Reid for his packaged geodetic segments, but with source names corresponding to those used in the normal SCHED catalog. Users are likely to just cut and paste that list into their schedules.

The example egdelzn.key includes three different source lists in GEOSRCS. One is Mark Reid’s original 60 sources. In testing, this list was found to be too sparse in some parts of the sky. The second list is the 295 defining sources of the ICRF2. This should be a good list, especially at frequencies not too far from the 2.3 and 8.4 GHz bands in which it was derived. The third list is based on the USNO 1cm survey and is should be the right one to use at 22 GHz and up. It also has over 200 sources.

The algorithm:

Note: There were minor changes to the algorithm when it got tested for 2 station observations. Those changes are not yet reflected in the description below.

As long as SCHED is producing good geodetic segments, the details of the algorithm shouldn’t matter too much to users. But some may wish to know, so it is described here. When starting to work on a segment, SCHED calculates the elevations at the middle of the segment for all of the specified sources. It assigns a priority for each source depending on how many stations see it at low (below GEOLOWEL) and high (above GEOHIEL) elevation. The best sources are low at at least two stations and high at at least two. The next priority sources have at least one low and three high stations or at least three low stations. The mix of low an high stations helps with the eventual least squares fit to SecZ terms. Higher priority numbers (worse sources) are assigned to less optimal sources. With the help of the calculated information and priorities, SCHED constructs a number ( GEOTRIES of trial geodetic segments. A quality measure for each segment is determined by setting up a least squares fit for SecZ and clock terms. The formal error on the fitted SecZ term for the station with the highest such error is the quality measure.

An algorithm is used to construct each tested segment that tries to come up with a source set that works reasonably well. This makes constructing each segment slow, but means that not many need to be tested. The algorithm starts by locating the 5 closest sources in the top two priority bins to the preceding source in the schedule. “Close” here means in terms of slew time for the array. For the first scan of the schedule, all qualified high priority sources are considered since the array will usually slew to the first source before the observations start. One of the chosen sources is picked at random. Then the next source is picked at random from the 5 closest sources that either add a high or a low observation to a number of stations that is the lesser of a third of the total or a third of the total number of low and high scans still needed. That scheme continues until there is at least one low and one high source for each station. That usually takes of order 6 scans.

For later scans in the segment, all sources given in GEOSRCS that are up at enough stations (set by OPMINANT) are tried, one at a time. A dummy least squares fit for SecZ and clock is tried with the sources in the segment so far, up to a maximum of the preceding GEOBACK sources. Restricting the number in the look-back seems to help some times when choosing long segments. The default is large (100) so there will be no effect and this should be good most of the time, but users might want to fiddle the value. Three quality measures are considered in the selection of the next source. The first is the improvement in the sigma for SecZ for the station that was worst with the already-selected sources, subject to a penalty for long slew times. If that is not sufficiently good, the source that gives the best improvement for the previously worst antenna without the slew penalty is selected, but with a requirement that the improvement be more significant than was required when the slew penalty was used. If even that is not sufficiently interesting, the source that gives the best RMS improvement in the SecZ sigmas across the array, subject to the slew penalty, is chosen. The deranged may wish to use GEOPRT to watch in detail , in sched.runlog, what is going on in the algorithm. Actually you can tell quite a bit from GEOPRT=0 but you will likely need to use the code to understand much of what is being spewed out, especially for a high value of GEOPRT such as 2.

Note that, in the fits, any SecZ of more than 4 (about an elevation of 15 degrees) is treated as 4. This will make the quality of the fits seem somewhat lower but will place less emphasis on scans that are so low that the risk of failures is great.

While selecting sources, normally no one source will be allowed to repeat. But sometimes there aren’t very many low elevation options and it may be desirable to allow repeats. Parameter GEOSREP sets the minimum number of scans that must go by before a source is allowed to repeat. This was a problem for the original 60 source list, but much less so for the ICRF2 or 1cm sources.

For each of the GEOTRIES trial segments, a quality measure is generated. SCHED picks the best segment according to the quality measure, and inserts that into the schedule. The quality measure is based on the expected errors of a fit for the zenith delay and clock for all stations. Standard errors of 100ps are set for all observations (the value doesn’t really matter here although a future enhancement would be to vary the number based on the source strength) and the highest reported sigma across the stations is used as the quality measure. This process is similar to what is done when the data are used and encourages both a high range of elevations at each site and a significant range of elevations across antennas for each scan.

2.9 Scheduling the VLA

For much detailed information on VLBI at the VLA, follow the links to the VLBI at the VLA guide.

The WIDAR correlator is capable of providing phased array output from the VLA in a VDIF format to be recorded on a Mark5C disk recording unit. Such data can be played back on the DiFX correlators, at least. Since recorder ready data are provided by WIDAR, none of the normal VLBI backends are used. But the properties of the correlator are rather similar to the RDBE so, in fact, scheduling the VLA has become more similar to scheduling other antennas than it was with the old system.

The SCHED output used by the VLA is the VEX file. In many ways, the setups are similar to those for the VLBA. The user does not need to worry about the details of the internal VLA LO setup, although the front end name ( FE) does need to be provided as there can be ambiguities. The software involved in translating the VEX file and making the VLA scheduling blocks (vex2opt) takes care of most details. The important factor is that the LO and baseband frequency specifications, taking into account the IF sideband, add up to the RF frequency of the bottom edge of the desired baseband. The bottom edge is required because the EVLA phased output is always net upper sideband.

As for setups, the VLA is fairly similar to a VLBA antenna. But there are several crucial differences. The VLA is now compatible with everything that the VLBA can produce (RDBE/PFB, RDBE/DDC-4 and RDBE/DDC-8). The channels on the VLA must come in polarization pairs. Each baseband must come from a separate IF with RCP in A or B and LCP in C or D. There are some cases above 18 GHz where the BD pair must be at a lower frequency than AC, but that mainly affects Ka band ( 30 GHz), which is not available on the VLBA. SCHED will not try to protect against that although the hooks are in the code in case of future need.

The restriction to net upper sideband needs to be considered when using the RDBE with the PFB personality on the VLBA. Either the VLBA LO needs to be above the RF frequency, or the sideband inverting capability of DiFX needs to be invoked. For some bands, a high VLBA LO is not possible so the DiFX mode will be needed. If the LO/sideband combination from a station for a channel spans the same RF range as the LO/sideband combination at another station, despite opposite sidebands, SCHED will detect the overlap and schedule for sideband inversion.

Sample schedules that include the VLA have been provided. One using the PFB personality of the RDBE at the VLBA is jvla.key (modify for 16 channels!). The WIDAR baseband channels can have much wider bandwidths than the PFB 32 MHz channels. They can be up to 128 MHz wide so, with 4, there is enough bandwidth to feed 2 Gbps, matching the output of the VLBA stations when they use the DDC personality of the RDBE. For an example of using 128 MHz bandwidths with WIDAR and the RDBE/DDC, see vladdc.key.

For scheduling, the user should be aware that the VLA slews at 40 deg/min in azimuth and 20 deg/min in elevation, which is about half the speed of the VLBA. This can be an issue for widely separated sources. It is, however, faster than some other HSA or Global VLBI antennas. The use of DWELL for scheduling should insure that adequate on-source time is obtained with the slower antennas.

Another issue is that, each time a frequency is seen for the first time, there needs to be a one minute dummy scan during which the levels of the analog signals into the samplers are set. SCHED can handle this when using DWELL scheduling by inserting the appropriate amount of time as a gap before the first scan with each frequency. The time required is given by the antenna catalog parameter TLEVSET. VEX2OPT will insert the required dummy scan in this gap. Alternatively, the user can explicitly insert DUMMY scans. These are scans that are not recording, not doing pointing, and not doing phasing and are at least as long as TLEVSET (1 minute for the VLA). SCHED will not try to insert a gap, or claim a late on-source time, based on TLEVSET before such a scan. It is traditional to put a series of such DUMMY scans at the start of the observing block, stepping through all the frequencies that will be used in the observing block. Note that an enhancement needed for the DUMMY scans on the VLA is to avoid needing DUMMY scans even for small frequency changes such as those associated with different Doppler frequencies for different sources.

ARRAY PHASING:

An important concern unique to the VLA and other interferometers used in phased array mode to generate a single data stream for VLBI is the need to adjust the individual antenna phases so that the signals add coherently when summed. The instructions to actively phase during a scan, to hold phase from a previous active scan, or not apply phase offsets are given in the VEX file in “intents”. The relevant intents are AUTOPHASE_DETERMINE, AUTOPHASE_APPLY, and AUTOPHASE_OFF. Each can be preceded by VLA: (eg VLA:AUTOPHASE_DETERMINE if there is a reason to make them specific to the VLA. They can be provided directly using the INTENTs input to SCHED, but SCHED will also generate them as needed based on VLAMODE parameter if that is used, which is recommended. The use of VLAMODE is preferred because the defaulting behavior between scans is cleaner — it does not get tangled with other uses of INTENTs. SCHED will not allow the use of both phasing INTENTs and VLAMODES as then can step on each other.

Phasing scans can be added simply as additional VLBI scans, or the VLA can be sent to a source not observed by the rest of the antennas and for which no recording is made.

For successful phasing of the array, a source must be greater than about 0.1 Jy (That is an old VLA number but is probably still reasonable. See the guide referenced above for details) and have a position that is good to a fraction of the VLA synthesized beam (enhanced sensitivity is only obtained over this area). It must have small structure phases and not have other sources of comparable strength in the primary beam that might confuse the phasing algorithm. The position accuracy is especially important if a calibrator is being used to phase the array for observations of another source.

Adding phasing sources is tricky, because it is desirable to spend a minimum amount of time on them, but if they are missed, the rest of the data will be bad. When phasing, the SCHED scan during which the phasing occurs is broken into subscans by the VLA as only one solution is done per subscan. The SCHED scan should be long enough for at least 4 such subscans. The length of the subscans is set by the scan-dependent parameter VLAPTIME in seconds. The default is 10 seconds which is reasonable for most good phasing sources and is the minimum SCHED will allow. If it is necessary to phase on a weak source, this could be extended. With the default subscan length, the SCHED scan for phasing should be at least 40 seconds on-source.

The interval between phasing scans depends on the observing frequency, the VLA configuration, and the weather. Intervals between 15 and 30 minutes are typical.

REFERENCE POINTING

At frequencies greater than 15 GHz, the VLA a priori pointing is not good enough so reference pointing must be used. That is also controlled through use of INTENsT.

****** Document how to insert pointing scans, and the use of automatic insertion of pointing scans.

The old parameter VLAPSRC allowed automatic insertion of VLA phasing scans in the observe files. That scheme no longer works. But an item on the to-do list is to make that parameter insert VLA phasing scans. That has not yet been done.

OTHER CONSIDERATIONS

If doing DELZN segments to measure the tropospheric delay, it is best to use a single dish mode as the phasing can take time and can confuse the troposphere solution algorithm.

It is still early days for VLBI observations using the WIDAR correlator to generate the phased array output data. This section will likely need more information eventually.

Note that normal output from the WIDAR correlator will be obtained during VLBI observations. Such observations may be useful for determination of large scale structure, total flux density, polarization, or absolute amplitude calibration. The user may need some VLA specific scans, such as on a flux calibrator, to make full use of such data.

This section has changed drastically with the advent of the upgrade to the VLA and the use of the WIDAR correlator. If you have a perverse interest in the old system, see the obsolete sections.

2.10 Special Concerns for Specific Observatories

.

WARNING: UNDER CONSTRUCTION!!!

This section contains various hints regarding the special requirements of specific observatories. Some of this information is lifted directly from email and other sources from the observatories.

This section is still woefully incomplete.

2.10.1 Green Bank Telescope.

There are a variety of concerns for scheduling the GBT. Documentation is maintained at Green Bank and can be accessed at the link: VLBI on the GBT:

More information may be added here eventually, but for now, use the above link.

2.11 Single Dish VLBA Observing

SCHED is used primarily to schedule VLBI observations on the VLBA and most of the rest of this manual is devoted to details of how to do that. However, there are a variety of types of observations that are rather different. These are mainly single antenna observations usually done to measure system performance. SCHED is able to make the schedules for these observations. Such observations are not likely to be of interest to users other than NRAO staff involved in the testing and maintenance of the instrument.

Some items of special interest for VLBA scheduling are:

SOURCE: The source name is used in the usual way. However, for pointing, there is a useful capability to specify the name of a Solar System object and have SCHED determine its location from a JPL ephemeris. See the description of SOURCE for more details.

OBSTYPE: This should be set to NONE for single dish observations.

CALCODE: If set to “L”, pointing data will be processed using differences between the on-line and off-line channels.

PTVLBA: This can be specified on a scan basis and causes SCHED to write out a pointing pattern. It can be turned off with NOPTVLBA

TAVLBA: This can also be specific on a scan basis, but not for a scan with PTVLBA. It is another special mode, very similar to PTVLBA, for measuring antenna temperatures. It can be turned off with NOTAVLBA.

PN3DB: This can be specified on a scan basis and causes SCHED to write out half power tracking test pattern. It can be turned off with NOPN3DB

AZCOLIM: This specifies a pointing offset in arcminutes in the azimuth direction. It is equivalent to the term used in the pointing equations to account for feed offsets so it is a constant angle on the sky. The actual change in azimuth increases at high elevation because of the cos(El) dependence of the angular effect of an azimuth change. It is available both in the setup file and in the main schedule.

ELCOLIM: This specifies a pointing offset in arcminutes in the elevation direction. It is equivalent to the term used in the pointing equations to account for feed offsets and encoder offsets, which are equivalent for elevation. It is in the setup file.

PTINCR: This is the jump in arc minutes between the on-source and half-power pointing positions for use in setting up pointing patterns. It is used in PTVLBA, PN3DB and TAVLBA modes. This is a setup file parameter.

PTOFF: This is the jump in arc minutes between the on-source and off-source pointing positions for use in setting up pointing patterns. It is used in PTVLBA, PN3DB, and TAVLBA modes. The default is 6 times PTINCR. This is a setup file parameter.

PTDUR: This parameter is a time (in the usual time format) that specifies the time spent in each pointing position of a pointing pattern. A reasonable value is 15 seconds.

PTSLEW: This parameter specifies the time to allow to slew to the source. It is specified in the usual time units (seconds). With dwell time scheduling or schedule optimization, it should be kept small, often equal to PTDUR.

FOCUS: This is used to increment the subreflector focus position. The value is added to the nominal value known to the on-line system for the particular receiver.

ROTATION: This is used to increment the subreflector rotation position. The value is added to the nominal value known to the on-line system for the particular receiver.

ROTPAT: This triggers generation of a focus-rotation test pattern of pointing observations.

ROTOFF: This is used to specify the rotation offset positions of a focus-rotation pattern.

FOCOFF: This is used to specify the focus offset positions of a focus-rotation pattern.

EPHFILE: This is the name of the ephemeris file to use if planets are included in the pointing, as they typically are at high frequencies. At the AOC, the ephemeris files are typically kept in a directory assigned the environment variable PLANET_DATA. That assignment can depend on computer architecture because the files are binary.

There are a number of setup files among the standard setups that are for VLBA test observations. Those that start with pt are for pointing or antenna temperature observations. Those that start with pc are for pulse cal tests.

In addition to the above parameters, it is often best to make use of one of the optimization modes to make the actual schedules. OPTMODE=SCANS is perhaps the most useful. With this mode, only a few template scans need be specified and SCHED will pick the ones appropriate for use in the desired time range. Below is an example of a script, including everything necessary to run SCHED on each VLBA station, for making pointing and gain check observations. This example is at a somewhat higher level of complexity than most in this document, but it shows what can be done with the program. It actually makes a different schedule for each station, taking into account the different portions of the sky that can be seen.

#!/bin/csh  
#  
#  Try with VEX file  
#  
# ========================================================  
# =====  Script to make pointing files for the VLBA  =====  
# ========================================================  
#  Set stations to be processed.  
#  Note that the case used here will appear in the sum and  
#  vex file names, so it is better to use lower.  
#  The schedules need to be different depending on whether  
#  a 3mm receiver is present.  
#  Examples:  
#  set stalist_3mm="hn nl fd la pt kp ov mk"  
#  set stalist_no3mm="br sc"  
#  set stalist_no3mm=""      eg use blank if no stations of this type.  
set stalist_3mm="pt hn"  
set stalist_no3mm="hn"  
 
#  
#  Set times and experiment code  
#  
echo Sched environment variable = $SCHED  
echo PLANET_DATA environoment variable = $PLANET_DATA  
cat <<eofp >! times.par  
  year    = 1996  
  month   = 10  
  day     = 25  
  start   = 0:00:00  
  opdur   = 4:00:00         !  Total project duration  
eofp  
set  expcode="ptg"  
 
# =====================================================================  
# =====================================================================  
# ======                                                         ======  
# ======      Changes not normally needed below this line.       ======  
# ======                                                         ======  
# =====================================================================  
# =====================================================================  
# Specify the location of the setup files.  
#  
setenv SETDIR $SCHED/setups  
#  
# Put much of the generic setup information in ptg_setup.par  
#  
cat <<eofs >! ptg_setup.par  
! ---------------------------------------------------------------------  
! SCHED input file setup stuff to be used with pointing proceedure doptg.  
 
! -----  Cover information  
version  = 1  
expt     = ’STARTUP pointing’  
obstype  = PTVLBA  
obsmode  = ’Multi-frequency pointing observations.’  
piname   = ’Operations’  
phone    = ’505 835 7251’  
obsphone = ’505 835 7251’  
fax      = ’505 835 7027’  
email    = ’vlbaops@nrao.edu’  
address1 = ’AOC’  
 
! -----  Catalogs etc.  
srcfile = ’$SCHED/catalogs/sources.pointing’  
stafile = ’$SCHED/catalogs/stations.dat’  
ephfile = ’$PLANET_DATA/JPLEPH.405.2’  
!ephfile = ’$SCHED/catalogs/JPLEPH.405.2.Linux’  
! -----  Schedule instructions  
sumitem = EL1, AZ1 ! Start elevation and azimuth in summary.  
ptvlba  
ptdur   = 15       ! => scan length = ptslew + 2*ptdur + N*10*ptdur  
                   ! The autoleveling scan is 2*ptdur long for pcx.  
                   ! Here we have 15+30+2*150 = 345s = 5:45  
dwell   = 5:45  
ptslew  = 15  
optmode = SCANS    ! Select scans that are above minimum elevation.  
opminel = 20.      ! Minimum elevation.  
 
eofs  
 
#  Now make a file with the actual schedule info for 3mm sites.  
#  Any imbedded catalogs etc must be here.  
 
cat <<eofs >! ptg_3mm.par  
! -----  Spectral lines  
! -----  Set up for 4 channels - 2 on line, 2 off.  
lineinit /  
 lineset =’H2O’    restfreq=22235.08,22235.08,22285.08,22285.08 /  
 lineset =’SiO431’ restfreq=43122.03,43122.03,43222.03,43222.03 /  
 lineset =’SiO862’ restfreq=86243.4, 86243.4, 86343.4, 86343.4  /  
endlines /  
 
! -----  The detailed schedule  
! The frequencies are in an order reasonable for FRM.  
!  50/90 cm  CYGA,    TAUA,    3C274  
!  20-4 cm   3C454.3, 3C123,   3C274  
!  2, 1 cm   DR21,    3C84,    3C274  
!  7 mm      RCAS,    RLEO,    WHYA, DR21, 3C84, 3C273, planets  
!  3 mm      RCAS,    RLEO,    WHYA, planets  
 
!  Group must equal the number of scans below.  
!  (Group*rep) must be less than 2000 (as of 18 Apr 1996).  
!  The 7mm line sources used to have qual=50.  This used to be the way  
!     to trigger line processing.  Now CALCODE=’L’ does it.  
!  Note that for a peak=1 scan, no reference pointing will be done  
!  if the slew takes longer than 40 seconds.  That is partly why  
!  there is a second peak scan.  
 
 
group=(10*3+8*3) rep=50  
 
setup=’$SETDIR/pt90cm.set’  source ’CYGA’    nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’DR21’    nodop   bw=0,0   /  
 
setup=’$SETDIR/pt7mm.set’   source ’JUPITER’ nodop   bw=0,0 qual=0  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45  /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45   /  
setup=’$SETDIR/pt7mm.set’   source ’RCAS’    doppler bw=2,2 qual=0  
  linename=’SiO431’  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45 /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45  linename=’SiO862’  /  
 
 
setup=’$SETDIR/pt90cm.set’  source ’TAUA’    nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’3C84’    nodop   bw=0,0   /  
 
setup=’$SETDIR/pt7mm.set’   source ’RLEO’    doppler bw=2,2 qual=0  
  linename=’SiO431’  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45  /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45  linename=’SiO862’ /  
setup=’$SETDIR/pt7mm.set’   source ’VENUS’   nodop   bw=0,0 qual=0  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45  /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45   /  
 
setup=’$SETDIR/pt90cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’3C273’   nodop   bw=0,0   /  
 
setup=’$SETDIR/pt7mm.set’   source ’WHYA’    doppler bw=2,2 qual=0  
  linename=’SiO431’  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45  /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45  linename=’SiO862’ /  
setup=’$SETDIR/pt7mm.set’   source ’SATURN’  nodop   bw=0,0 qual=0  
  noptvlba peak=1 dwell=01:00  /  
  noptvlba peak=1 dwell=01:00  /  
  nopeak ptvlba   dwell = 5:45  /  
  setup=’$SETDIR/pt3mm.set’   nopeak ptvlba dwell = 5:45   /  
 
! ---------------------------------------------------------------------  
eofs  
 
#  Now make a file with the actual schedule info for sites without 3mm.  
#  Any imbedded catalogs etc must be here.  
 
cat <<eofs >! ptg_no3mm.par  
! -----  Spectral lines  
! -----  Set up for 4 channels - 2 on line, 2 off.  
lineinit /  
 lineset =’H2O’    restfreq=22235.08,22235.08,22285.08,22285.08 /  
 lineset =’SiO431’ restfreq=43122.03,43122.03,43222.03,43222.03 /  
 lineset =’SiO862’ restfreq=86243.4, 86243.4, 86243.4, 86243.4  /  
endlines /  
 
! -----  The detailed schedule  
! The frequencies are in an order reasonable for FRM.  
!  50/90 cm  CYGA,    TAUA,    3C274  
!  20-4 cm   3C454.3, 3C123,   3C274  
!  2, 1 cm   DR21,    3C84,    3C274  
!  7 mm      RCAS,    RLEO,    WHYA, DR21, 3C84, 3C273, planets  
!  Group must equal the number of scans below.  
!  (Group*rep) must be less than 2000 (as of 18 Apr 1996).  
!  The 7mm line sources used to have qual=50.  This used to be the way  
!     to trigger line processing.  Now CALCODE=’L’ does it.  
 
linename=’SiO431’  
 
group=(12*3) rep=60  
setup=’$SETDIR/pt90cm.set’  source ’CYGA’    nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C454.3’ nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’DR21’   nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’DR21’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’RCAS’    doppler bw=2,2 qual=0 /  
setup=’$SETDIR/pt7mm.set’   source ’JUPITER’ nodop   bw=0,0 qual=0 /  
 
setup=’$SETDIR/pt90cm.set’  source ’TAUA’    nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C123’   nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’3C84’   nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’3C84’    nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’RLEO’    doppler bw=2,2 qual=0 /  
setup=’$SETDIR/pt7mm.set’   source ’VENUS’   nodop   bw=0,0 qual=0 /  
 
setup=’$SETDIR/pt90cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt18cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt6cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt13cm.set’  source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt4cmsx.set’ source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt1cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt24ghz.set’ source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt2cm.set’   source ’3C274’   nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’3C273’   nodop   bw=0,0   /  
setup=’$SETDIR/pt7mm.set’   source ’WHYA’    doppler bw=2,2 qual=0 /  
setup=’$SETDIR/pt7mm.set’   source ’SATURN’  nodop   bw=0,0 qual=0 /  
! ---------------------------------------------------------------------  
eofs  
 
#  
# Now run sched separately for each 3mm station.  
#  
foreach station ( $stalist_3mm[1*] )  
   echo station=vlba_$station >! station.par  
   echo expcode=$expcode >> station.par  
   $SCHED/bin/sched <<eofst  
       @times.par  
       @station.par  
       @ptg_setup.par  
       sch = ptg_3mm.par  
       overwrit /  
eofst  
#  
#  Make the sum and vex files station dependent.  
#  
   /bin/mv ptg.sum ptg.$station.sum  
   /bin/mv ptg.vex ptg.$station.vex  
end  
#  
# Finally run sched separately for each no 3mm station.  
#  
foreach station ( $stalist_no3mm[1*] )  
   echo station=vlba_$station >! station.par  
   echo expcode=$expcode >> station.par  
   $SCHED/bin/sched <<eofst  
       @times.par  
       @station.par  
       @ptg_setup.par  
       sch = ptg_no3mm.par  
       overwrit /  
eofst  
#  
#  Make the sum and vex files station dependent.  
#  
   /bin/mv $expcode.sum $expcode.$station.sum  
   /bin/mv $expcode.vex $expcode.$station.vex  
end  
#  
#   Some clean up.  
#  
#/bin/rm times.par  
#/bin/rm ptg_setup.par  
#/bin/rm ptg_3mm.par  
#/bin/rm ptg_no3mm.par  
#/bin/rm station.par  
#  
#   END  

2.12 Configuration Studies

SCHED has capabilities, added in 2002, that are useful in array configuration studies. These are tied to the plotting capabilities. If OBSTYPE = CONFIG is specified and a UV plot is requested from the interactive plotting menu with more than one requested source, a map of the station locations is plotted first. It is possible to adjust station selection by clicking on this map, and it is even possible to move stations. Also, the station selection can be used to set up a configuration optimization that uses, as a quality measure, some statistic about the sampled cells in a grid. Alternatively, a contour plot of the quality measure around a selected station can be made. The effect of multifrequency synthesis can be examined with the help of the UVMFS parameter. This all makes for a rather interactive way of examining possible configurations. The style is much like that used for the VLBA configuration search, but is far more modern and interactive. The optimizer is fast enough that a 1.8 GHz Pentium IV under Linux, optimizing arrays of 20 stations using 12 hour tracks of 10 minute scans on 4 sources can process over 50 different configurations per second. To describe the capabilities, the steps involved in using them will be described.

First, start with a planning type schedule such as is described in the schedule planning section. The scan characteristics can be adjusted at will. The examples are good for “hunt and peck” configuration examinations. For the optimizer, which looks at the uv points at the beginning and end of scans, it is useful to use something like DUR = 10:00 and GAP = 10:00 to evenly space these points. Recall that setting the frequency to 0.3 MHz (the default for uv plots when no setup is given) gives a one kilometer wavelength so the UV coverage is in km.

There are two ways to look at alternative arrays. One is to specify a lot of stations up to the maximum that SCHED will accept. Then the ones to include in the uv plots can be selected from the sources menu or interactively from the map. This allows rapid trials of many options. As and alternative, or in addition, any station can be moved interactively. Note that you can use OPTMODE=UPTIME to get continuous tracks on each source, or you can give an actual schedule. The author has found it useful to invoke two instances of SCHED and carefully align the plot windows (most easily by expanding them to full screen). Then the window manager can be used to blink back and forth to see differences easily. Of course, selecting the station of interest to highlight (plot uv points in red) helps distinguish differences too.

Note that, you can adjust the maximum number of stations by setting the FORTRAN parameters MAXSTA in sched.inc, and PSTMAX in plot.inc. You might also have to increase MK in schin.f to increase the allowed number of input parameters. If you just change MAXSTA, SCHED should complain about other changes that are needed. Be warned that, as these parameters are increased, the size of SCHED increases significantly since they affect several 2D arrays with MCHAN, which is rather large, on the other axis. Average users are not expected to do this sort of thing, but if you are doing serious configuration studies, you are probably not an average user.

The latitude and longitude range to set for the map should be set using MAPLIM. SCHED will examine these ranges and look for vector files that provide useful geographic information. If the region is large, country and ocean boundaries are plotted. If the US is included, state boundaries are also plotted. Finally, if New Mexico is of significant size, the roads in New Mexico will be plotted (this facility is being used for New Mexico Array - a part of the EVLA - configuration studies). For now, the map file names are hardwired to be $PLANET_DATA/wdbtemp4.e00 for the world map, $PLANET_DATA/states.e00 for the US states map, and $PLANET_DATA/tra0003-2.dat for the NM roads map. $PLANET_DATA is an environment variable used locally to point to the directory where the planetary ephemeris is kept. The maps will not be distributed with SCHED (they are much larger than all the rest of SCHED put together), but can be made available to interested users.

Start SCHED in the manner for plotting (specify PLOT and the schedule file). Once the menu comes up, set various things. Under Options, it is useful to decrease the default line widths. Under AXIS, select UV Plot and set the desired scale. It is useful to reverse the signs of the X axis so that the UV tracks can be easily associated with stations on the map. Under files, select Both stations selected so that any unselected stations are left out of the plot. Also select the sources you wish to use. I have defined several sources at different declinations and at ra=0 for these studies and like to use the ones at 44, 18, -6 and -30 degrees as a representative sample. Then it is a good idea to save all this in a parameter file from the FILES page. On the next run, loading that parameter file can save all the other setups. Finally, click on PLOT.

At this point, a map will appear with selected stations in blue or red and unselected stations in yellow or yellow with a red central dot. You can right click on the map and the uv coverage for your sources will be plotted. You can drag the corners of the pgplot window to make it larger, if you wish, or let the window manager expand it to full screen. The next plot (click PLOT again) will then be larger. In the uv plots, any baseline involving a highlighted (red) station will be plotted in red. Others will be plotted in blue. Left clicking on the map will toggle the selection status of the nearest station to the cursor. Middle clicking on the map will flag the nearest station to be moved. The next left click (maybe others too) will put that station at the cursor position. Note that you cannot return a station to its original position without restarting the program. Once a station has been moved, its symbol will be surrounded by a green ring and, in the station list printed with the uv plots (right click), the position will be in green. Checking configurations involves clicking stations on and off and running the uv plots.

The map can be zoomed in and out with ’Z’ and ’z’ respectively. The zoomed image will be centered at the location of the cursor when the letter was typed. The zoom out is by a factor of 1.5, in by a factor of 1.0/1.5.

The optimizer is triggered by typing the letter O (not case sensitive) while the cursor is on the map. What it does is count all the highlighted stations, then it tries all combinations of that many stations, choosing from all stations shown either in red or yellow with a red dot. Thus you can use the toggle operation to select that stations that will be tried with the optimizer. Be warned that the number of arrays to try can get very large if you try to optimize too many stations at once. SCHED will inform the user of the number it plans to try and then tells about its progress so he/she can decide whether to wait and watch, go get a cup of coffee, go to bed, or abort the process (kill the job - I suppose some day this should be made friendlier).

The optimizer calculates a quality measure for each array and ranks the resulting arrays accordingly. The quality measure is based on statistics of sampled cells in a special grid. There are two options, one is to simply count the number of sampled cells. The other is to look at the rms scatter of the number of samples per cell. Other quality measure options could be added without a lot of trouble. Some details are written to the nnnn.opt file (nnnn is the project code), including the results for the top 200 arrays.

The optimizing grid is a polar with a radial cell size that scales with the root sum of the radius squared plus a constant squared. If the constant is small, this ends up scaling with radius (a logarithmic grid) which is useful for large arrays that cannot be reconfigured to adjust the resolution. For a large constant, the cells are evenly spaced in radius, which places more importance on the longer spacings. With an intermediate constant (the constant is in the units of the UV plot), the cells have even spacing in the middle and go toward scaling with radius on the outside. This has been found to be the most useful case, which is why this complexity is included. If the constant is too small, arrays that are excessively centrally condensed are generated. If too large, there can be poor short spacing coverage. You will need to experiment with the values. Also, you will need to experiment with the number of cells to use in the radial and azimuthal directions. If the cells are too small, you will not distinguish between arrays very well (each track is effectively isolated). If too large, all arrays will fill most or all cells so again this will not be a good test. After an optimization, there will be a faint representation of the grid plotted under the UV coverage plots.

The parameters of the grid are set with GRIDNR (the number of radial cells), GRIDNT (the number of azimuthal cells), GRIDMIN (the inner radius of the grid), GRIDMAX (the outer radius of the grid - which can bias the resulting size of the array), GRIDW0 (the constant discussed above), GRIDMEAS (select the quality measure), GRIDSTEP (select the spacing of latitude and longitude points calculated for making the contour plot of quality — see below), and GRIDVLA (restrict the quality measure calculation to only baselines involving a VLA station).

In addition to optimization, SCHED can plot contours of the quality measure around a selected station. To invoke this, toggle the station selections until only one is red (if more are red, only one will be used), then type S. Sched will calculate the quality measure with the selected station at points on a latitude and longitude grid, spaced by GRIDSTEP arc minutes, and then present a contour plot of the results. This can be useful for finding directions to move a station to improve coverage and for finding the area over which a station can be moved to account for logistical considerations. The contours will remain until the map is replotted, so if you repeat the process, multiple versions can end up on the plot. On replot, the contours will be replotted unless some other action, like station selection or moving, has been taken. This allows hard copies including the contours invoked from the files menu to be made for printing or whatever.

When the station map first appears, it is in full screen mode. But when you right click to get the uv plots, it is replotted in one of the panels.

If one clicks ’K’ on the map, two postscript files are produced that are useful for VLA centered SKA configuration studies. These are highly specific outputs with many parameters hardwired, so they are not expected to be useful to the general user. Someday, they may be generalized.

Note that it would not be hard for a user willing to do a bit of FORTRAN programming to cause other maps to be plotted or to add other optimization quality measures. If you want to do so, please let Craig Walker know (cwalker@nrao.edu) so we can integrate a way to choose the modes and input parameters and keep from having multiple versions of SCHED. It is also just a matter of changing a few parameter statements to increase the number of allowed stations. This is kept down for the released version of SCHED because that dimension is combined with other large ones, like the maximum number of scans, to set the size of some arrays and not everyone has huge memory computers.

These facilities were added by Craig Walker in early 2002. Putting them in SCHED was the easiest way to obtain facilities long wanted for UV studies. This scheme for UV optimization is especially useful for arrays of relatively small numbers of antennas with strong geographic constraints, as opposed to large arrays laid out on an open plain.

2.13 Satellite Tracking

There was a project to use the VLBA to provide positional data to help navigate interplanetary spacecraft. For this project, the VLBA must be able to point at the spacecraft so the ability to do so was added to SCHED as of March 2004. The spacecraft positions are obtained with the help of spice files that are typically from JPL. In Dec. 2014, this capability was augumented to utilize TLE (Two Line Ephemeris) files.

The NAIF software package from JPL is called to read the spice files and calculate positions. It is also used in processing the TLE files. The NAIF software significantly increases the size of a SCHED distribution, and the satellite tracking capability is unlikely to be needed outside the AOC. Therefore the tracking capability is not included in the default SCHED distribution.

To use the tracking capability, a Satellite Initialization section needs to be included in the main input file. That section contains a group of inputs for each satellite. There are four input parameters in each group:

Note that the satellite routines also set the velocity for the satellite for use with DOPPLER. The satellite frequencies can be specified with their rest frequencies in a LINEINIT section.

There seems to be an incompatibility between the NAIF software used for satellite tracking and the code used for tracking planets based on a JPL ephemeris that is used elsewhere in SCHED. It is best not to mix the two. The satellite ephemeris files typically also contain the planets so, if you wish to point at both satellites and planets, you can do it with the satellite files alone. Just don’t set ephfile.

Note that, according to notes in the code, this satellite tracking section of SCHED does not take into account diurnal aberration which it should, because it is also not taken into account in the on-line system. The planet section of sched does take it into account. This leads to different calculated positions when using the ephemeris and when using the satellite tracking. Some day, this should all be handled better, but the effect is under an arcsecond so it does not matter for pointing antennas.

The items in the SATINIT section are:

  1. SATNAME: The name of the satellite. This is only used internally in SCHED. It is the name that should be used as the SOURCE in the scan inputs. This name is not sent to the NAIF software.
  2. SATNUM: The number, used in the spice files, for the satellite (or other celestial body, for that matter). This number is assigned by JPL. You need to know this number but I’m not really sure how you get it. This number is sent to the NAIF software to tell it which satellite to process. For satellites, these numbers are negative. They are positive for planets etc.
  3. KERFILE: A spice kernel file that gives information such as leap seconds. It is likely to have the extension .tls. Standard versions at NRAO are in the $PLANET_DATA area.
  4. SATFILE: The spice file for the satellite. It is likely to have the extension .bsp. Note that it must contain the satellite (or asteroid or whatever) you want to observe AND any other bodies needed to calculate the vector from the antenna to the body. That will usually mean that the Earth should be included and might require others, especially if the satellite is orbiting around some other body.
  5. TLEFILE: The Two Line Ephemeris file for the satellite. It is likely to have the extension .bsp.

When groups have been given for all satellites, give a line that contains the word ENDSAT and a slash.

If the above section is provided and one of the satellites is a source in the schedule, SCHED will call the NAIF software once for a nominal position for the summary file etc, then again for every scan for every stations to get updated positions and rates. It will also calculate an approximate parallax correction for each station. This can amount to several arcseconds, and the calculation is believed to be good to an arcsecond or better. The scan/station dependent positions are written to the .crd files for the VLBA. See the note below about VEX files.

For a satellite (or any moving source, for that matter), SCHED plotting can help you see where the object is going. In the RD (RA/Dec) plots, a line will be plotted for each scan. A likely use for this capability would be to obtain the transmission schedule for a satellite over some days or weeks, make a schedule with a scan for each period that it is transmitting, then make the RD plot and show the calibrators. This will help identify times when the satellite is both on and near a likely phase reference source.

There is a SCHED example, egsat.com that demonstrates the use of the satellite capability. Interested users are recommended to start with that example.

The scheme for handling moving sources in VEX files is not yet established. However, to correlate such observations on the VLBA DiFX correlator, a Vex file is needed for all the information other than the positions. Thus VEX files can be written when there are moving positions, but several warnings will be written about the use of such files. The positions of the moving sources should be obtained from ephemeris information at correlation time, separately from the VEX file. For pointing, positions may or may not be good enough depending on the rates. Also note that solar system objects may require offset pointing positions between different stations and that is not described in the VEX file.

Chapter 3
THE SCHED INPUT FILES (Includes parameter lists)

This chapter covers the main input files that SCHED reads. However note that there are a couple of special purpose files that are covered in other sections. The input for specification of spectral line rest frequencies is covered in the section on spectral line observations. The input to control insertion of reference pointing scans is covered in the section on reference pointing.

See the SCHED Input and Output Files section of this manual for brief descriptions of the files and pointers to the standard versions.

3.1 The Schedule File

The schedule file is the main, and perhaps only, input file that the user prepares. It provides bookkeeping information for telescope and correlator operators, points to the desired catalogs or contains segments of catalogs, gives overall control commands to describe the observations and lays out the detailed sequence of observing scans.

A large number of input parameters are available for the schedule file. They are all described in detail in this section. However, most of the parameters default to reasonable values for ordinary VLBI observations and can be ignored by most users. The easiest way to determine which ones to worry about is to follow one of the examples and consult the detailed descriptions only when unsure of the meaning or behavior of a parameter.

The descriptions of the parameters for the schedule file, and later for the setup files, contain a wealth of information about VLBI systems and scheduling style. Serious users might find it instructive to browse through these sections.

This section starts with list of the parameters, with one line per parameter and, for web users, a link. When a parameter is given as mixed upper and lower case, the lower case letters are optional in the input file. The main part of this section is the detailed descriptions of every parameter. These descriptions start with some text describing the parameter, its actions, and information about how to use it. Every parameter description ends with a short table giving the following information:

Argument: The data type expected.

Options: A list of specific options if appropriate.

Default: The value assigned by SCHED if the parameter is not given in the schedule file.

Usage: Can the parameter be specified for each scan or only once? If for each scan, what happens if it is specified for one scan and not the next.

Example: An example specification of the parameter.

If a parameter for which SCHED only wants one value is specified for more than one scan, only the last value will be used. For parameters that can be specified for each scan, nearly all default to the value for the previous scan if not specified. The only exceptions are START, STOP, REP, GROUP, POINT, and COMMENT. Normal defaulting for these parameters would produce undesirable behavior. Note that TAPE, REWIND, FASTFOR, REVERSE, are not obsolete because they were specific to tape, which is no longer in use.

3.1.1 Summary List of SCHED Parameters

COVER INFORMATION:

VERSION:  Schedule version number. Helps identify latest.

EXPT:     Short description of project.

EXPCODE:  Project code.

PINAME:   Name of Principal Investigator.

ADDRESS1: Principal Investigator’s address for cover

ADDRESS2: information. Up to 4 lines allowed.

ADDRESS3:  

ADDRESS4:  

PHONE:    Principal Investigator’s phone number.

OBSPHONE: Principal Investigator’s telephone number during obs.

TELEX:    Principal Investigator’s TELEX number (obsolete).

EMAIL:    Principal Investigator’s electronic mail address(s).

FAX:      Principal Investigator’s FAX number.

OBSMODE:  Frequency band, recording system etc.

OBSTYPE:  Type of observation. Mostly for recorder control

NOTE1:    1st of 4 comment lines for cover information.

NOTE2:    2nd of 4 comment lines for cover information.

NOTE3:    3rd of 4 comment lines for cover information.

NOTE4:    4th of 4 comment lines for cover information.

COVERLET: Flag that in-line cover letter follows.

CORRELATOR INFORMATION:

CORREL:   Correlator to be used. Destination for recordings and log files.

CORAVG:   Correlator average time.

CORAVG2:  Alternate correlator average time.

CORCHAN:  Number of spectral channels per baseband channel.

CORNANT:  Number of antennas to be correlated.

CORPOL:   Polarization processing on or off.

CORSRCS:  Origin of source positions for correlator.

CORWTFN:  Correlator weighting function.

CORTAPE:  Type of media on which to send correlator output to user.

CORDFMT:  Format of export data.

CORSHIP1: Shipping address for correlator output.

CORSHIP2:

CORSHIP3:

CORSHIP4:

CORNOTE1: Notes for correlator operations.

CORNOTE2:

CORNOTE3:

CORNOTE4:

PROGRAM CONTROL:

DEBUG:    Turn on various debugging printouts.

OVERRIDE: Flag for programmers to bypass restrictions.

DOSTA:    Restrict processing to specific stations.

DOVEX:    Write a VEX file.

VEXTEST:  Allow use of unreleased VEX features.

EXIT:     Finish interactive input.

OVERwrit: Overwrite files from previous run of SCHED.

PLOT:     Invoke plotting part of SCHED.

SCHedule: Name of file containing rest of schedule.

FREQLIST: Write some information from the frequency file to frequencies.list and quit.

NOSETUP:  Do not use a setup. For planning schedules.

CATALOGS and other other “external” input.

LINEINIT: Following inputs will be rest frequencies.

SETINIT:  Name and flag for in-line setup data.

SRCCAT:   Flag for start of in-line source catalog.

SRCFILE:  Name of external source file.

SRCFILE2: Name of second external source file.

STACAT:   Flag for start of in-line station catalog.

STAFILE:  Name of external station file.

LOCFILE:  Name of locations file.

TAPEFILE: File name for tape initialization information.

TAPEINI:  Flag that next group of input is tape initialization.

EPHFILE:  File containing JPL ephemeris data for planets.

FREQFILE: File containing standard frequency setups.

PEAKFILE: File with reference pointing parameters.

PEAKINIT: Following inputs are for reference pointing.

PCENTERS: Flag for start of lists of multiple phase centers

GENERAL CONTROL PARAMETERS:

CALTIME:  Integration time for calibration data.

DODOWN:   Keep down antennas in scans.

DOSCANS:  Keep only this scan range. Mainly for operations.

WRAP24:   Double a 24 hour schedule to allow different start.

IATUTC:   IAT-UTC for planetary motion cards at VLA.

INTENTs:  Directives for observing, correlation, and processing.

LINEPG:   Number of lines per page in operator schedules.

LST:      Schedule is in LST for specified station.

NCHAN:    Number of baseband channels (Obsolete - set in setups).

PRECDATE: “Observe” date for coordinate conversions.

SUMITEM:  Items to show in the summary file.

TANTSTA1: List 1 of stations for Ta measurement requests.

TANTSTA2: List 2 of stations for Ta measurement requests.

BASIC SCAN TIMING and CONFIGURATION:

STATions: Station list for scan. Up to 30.

SOURCE:   Source name.

QUAL:     Qualifier for source.

YEAR:     Year of first scan stop time.

MONTH:    Month number.

DAY:      Day number. 1 is first day of MONTH. Can be day of year.

START:    Start time of scan.

STOP:     Stop time of scan.

DURation: Duration of scan.

DWELL:    Duration of scan but start when antennas on source.

GAP:      Minimum interval between scans.

PRESCAN:  Time to wait before starting recording (Obsolete).

PRESTART: Time to start recording before scan start.

PREEMPT:  Protect scan from preemption at PT and MK for EOP observations.

GROUP:    Number of scans to repeat.

REPeat:   Number of times to repeat scan(s).

SETUP:    Name of file containing VLBA setup information.

COMMENT:  Comment to appear in schedule.

SCANTAG:  Name for scan to put in summary tables.

SCAN PROPERTIES:

LINENAME: Name of group of rest frequencies to use.

DOPINCR:  Minimum increments for frequency setting.

DOPPLER:  Set frequency based on velocity for spectral line.

NODOP:    Turn off Doppler calculations.

DOMKA:    Record on Mark5A during Mark5C observations.

DOPCAL:   Obsolete form of DOPPLER.

DOPSRC:   Set frequency based on velocity of this source.

FREQ:     Up to 16 baseband channel sky frequencies for VLBA.

BW:       Baseband channel bandwidths.

CRDCH1:   First main channel for related VLBA legacy channel.

CRDNCH:   Number of VLBA legacy system channels.

CRDFREQ:  Force VLBA legacy BBC frequencies separate from RDBE.

CRDBW:    Force VLBA legacy BBC bandwidth separate from RDBE.

CRDDOP:   Provoke Doppler setting of VLBA legacy BBCs separate from RDBE.

CRDNODOP: End Doppler setting of VLBA legacy BBCs separate from RDBE.

CRDSETCH: List of setup baseband channels to use on VLBA legacy system.

PCAL:     Mode for pulse cal generators.

CENTERS:  Use multiple phase centers in processing.

PEAK:     Peak up on source.

NOPEAK:   Turn off peak up request.

POINT:    Convert the scan to a reference pointing scan.

PKWATCH:  Extra output when AUTOPEAK selected.

TANT1:    Turn on Ta measurement at the TANTSTA1 stations.

TANT2:    Turn on Ta measurement at the TANTSTA2 stations.

TSYS:     Turn on Tsys measurements (obsolete)

NOTSYS:   Do not measure system temperature (obsolete)

GEOSEG:   Insert a geodetic (DELZN) segment.

GEOSRCS:  Gives a list of sources for geodetic segments.

GEOPRT:   Turn on debugging print from geodetic insertion.

GEOTRIES: Number of trial geodetic segments to test.

GEOBACK:  Number of look-back scans while selecting geodetic segment sources.

GEOSLEW:  Relative weight of slew time in selecting geodetic segment sources.

GEOSLOW:  Stations getting to source this much later than others can be left out of a scan in a geodetic sequence.

GEOSREP:  Minimum number of scans between repeats of the same source in a geodetic sequence.

GEOLOWEL: Upper boundary of “low” elevation region for geo sources.

GEOHIEL:  Lower boundary of “high” elevation region for geo sources.

PN3DB:    Do VLBA half power tracking tests.

NOPN3DB:  Turn off VLBA tracking tests.

PTVLBA:   Do VLBA pointing sequence.

NOPTVLBA: Turn off VLBA pointing measurements.

TAVLBA:   Request Tant measuring mode.

NOTAVLBA: Turn off VLBA antenna temperature measurements.

PTDUR:    Duration of each step in VLBA pointing sequence.

PTSLEW:   Time to allow for slewing to source in pointing sequence.

AZCOLIM:  Azimuth collimation offset for scan for VLBA.

ELCOLIM:  Elevation collimation offset for scan for VLBA.

FOCUS:    Focus offset for scan for VLBA.

ROTATION: Subreflector rotation offset for scan for VLBA.

ROTPAT:   Expand pointing patterns to include focus/rotation.

ROTOFF:   Rotation offsets for ROTPAT pattern.

FOCOFF:   Focus offsets for ROTPAT pattern.

CRDLINE:  Arbitrary line for VLBA files for on-line testing.

RECORDER CONTROL

MINPAUSE: Minimum record stop time between scans.

RECord:   Record this scan. Non-zero or NOREC to not record.

NORECord: Do not record this scan.

The following parameters are obsolete as they only applied only to tape.

AUTOTAPE: Request automatic tape changes. Give tape time.

FASTFOR:  Fast forward the wide band tape.

REWIND:   Rewind wide band tape.

REVERSE:  Reverse direction of recording of wide band tape.

TAPE:     Force a tape change. Reset AUTOTAPE reference time.

TPREF:    Reference time for Mark II tape changes.

TAPESYNC: Synchronize tape changes (see warnings).

eVLBI CONTROL:

DATAPATH: Controls where data goes first.

GRABTO: Controls where recorded data goes.

GRABTIME: Controls which data are sent.

GRABGAP: Controls how much time is needed to send data.

OPTIMIZATION (Beware — experimental features!):

OPDUR:    Duration for experimental optimizing mode.

OPELPRIO: Two elevation ranges in which OPSKIP not active.

OPMINEL:  Minimum elevation for an ”up” source.

OPMINANT: Minimum number of antennas in a scan.

OPMISS:   For OPTMODE = SCANS, only keep this scan if this many scans have been skipped.

OPNOSUB:  Don’t subarray in experimental optimizing mode.

OPSKIP:   Skip source OPSKIP times unless in priority elevation range.

OPTLOWT:  Time scale for low el samples in OPTMODE = CELLS or CSUB.

OPTMODE:  Optimization mode.

OPPRTLEV: Print level for optimizing routine (mainly mode HAS).

OPTSLEW:  Time scale for slews in OPTMODE = CELLS or CSUB.

OPHA:     Prefered hour angle for scan OPTMODE=HAS.

OPHAWID:  Tolerance for hour angle OPTMODE=HAS.

OPHAWT:   Importance of HA vs other weights OPTMODE=HAS.

OPHASTA:  Reference station for hour angles OPTMODE=HAS.

OPMINSEP: Minimum separation of scans on a source OPTMODE=HAS.

OPSLEWWT: Importance of slew time vs other weights OPTMODE=HAS.

OPSLEWTI: Scale time for slew time weights OPTMODE=HAS.

OPHLIMWT: Importance of near limits vs other weights OPTMODE=HAS.

OPHLIMTI: Importance of HA vs other weights OPTMODE=HAS.

OPHMAXDT: Maximum offset from desired HA to consider OPTMODE=HAS.

HIGROUP:  Group a few scans from which to choose one based on El.

AUTOPEAK: Insert reference pointing scans.

MAPLIM:   Lat/long limits for station map when OBSTYPE=CONFIG

GRIDNR:   Number of radial cells in uv optimization grid.

GRIDNT:   Number of azimuthal cells in uv optimization grid.

GRIDMIN:  Inner radius of uv optimization grid.

GRIDMAX:  Outer radius of uv optimization grid.

GRIDW0:   Characteristic radius for linear to logarithmic grid spacing.

GRIDSTEP: Set the spacing of points for quality grid around a station.

GRIDMEAS: Set which quality measure to use.

GRIDVLA:  Specify that only baselines to VLA antennas are to be used.

UVMFS:    Show effect of MFS in UV plots.

SPECIAL VLA PARAMETERS:

VLAINTEG: VLA correlator integration time.

VLAPTIME: Duration of phasing subscans on the EVLA

VLAMODE:  VLA observing mode.

VLAPEAK:  Control reference pointing.

VLANTSYS: Turn off VLA system temperature corrections.

VLAPSRC:  Phasing source for VLA observations.

VLARFANT: Reference antenna for single dish or phasing.

VLATSYS:  Turn on VLA system temperature corrections. Also VLANTSYS.

VLATYPE:  Type of VLA observations.

VLAUSERN: Obsolete - VLA user number.

3.1.2 Details of SCHED Parameters

ADDRESS1, ADDRESS2, ADDRESS3 and ADDRESS4

ADDRESS1, ADDRESS2, ADDRESS3, and ADDRESS4 are used to give the Principal Investigator’s address for the cover information. At least the first line must be provided if recording.

Argument: A character string of up to 64 characters for each of the 4 parameters.

Options: Any.

Default: Blank

Usage: Only one value used, the last.

Example: ADDRESS1=’1003 Lopezville Rd’

ADDRESS2=’Socorro, NM 87801

ADDRESS3=’ U S A

AUTOPEAK

AUTOPEAK, without an argument, is used to request automatic insertion of reference pointing scans based in information in the PEAKFILE (which can also be specified in the schedule input file using PEAKINIT). See the section on reference pointing for much more information. Note that specifying AUTOPEAK will cause SCHED to try to insert pointing scans, but does not guarantee that it will find scans at high enough frequency or with enough of a gap from the previous scan. Scans will be inserted when it has been at least 10 minutes since the last set of pointing measurements and when there is adequate time for one or two pointing patterns based on the dwell time in the PEAKFILE. This can be triggered by specifying specifying adequate gaps using GAP. In such circumstances, the pointing will be inserted during the specified gap. The minimum interval between the original scans will maintain the interval from GAP, but the pointing will be inserted during that time. The interval between the inserted pointing scans and the input scan will typically end up much less than GAP.

Argument: No argument. Just specifying it turns on the attempts to insert scans.

Options: None

Default: Not set. Will not attempt to insert scans.

Usage: If set anywhere in the schedule, scan insertion is turned on.

Example: AUTOPEAK

AUTOTAPE

AUTOTAPE is an obsolete parameter that only applied to tape. It can be ignored by users of disk-based recording systems (eg Mark5) and eVLBI.

AUTOTAPE is used to request that automatic tape allocation and control be used at stations that use the VLBA control system and have more than one tape drive. It has no effect on other stations such as those that use VEX or on VLBA controlled stations with only one tape drive. AUTOTAPE=1 or AUTOTAPE=2 causes the on-line system to determine the tape direction, head position and track allocation automatically. The schedules will only include instructions on whether to run, stop, or rewind. AUTOTAPE>=2 also activates automatic reversal of the tapes when the low tape mark is reached, even in the middle of scans; with AUTOTAPE=1 the tape will stop at the low tape point and wait for the next scan. The default action (any other value of AUTOTAPE including no value) is to have SCHED determine the tape motion and related information.

Automatic tape allocation is now required for most VLBA observations. AUTOTAPE=2 should therefore be specified in most schedules. AUTOTAPE=1 is risky and probably should not be used. It is provided only so that SCHED can create schedules for all modes that the on-line systems can handle.

Automatic tape allocation cannot be used for projects that will not be correlated on the VLBA correlator. SCHED will refuse to make such schedules. This relates to how the correlators learn how the tape was handled at the stations. Non-VLBA correlators generally obtain some of the tape positioning information from the schedules rather than the logs, and, with automatic allocation, the two can be very different.

When automatic tape allocation is specified (AUTOTAPE=2), any station that is using the automatic allocation will be removed from a scan if the source is below the hardware limits at both ends of the scan. One can tell when this happened because a “D” will appear next to the --- in the summary file elevation and azimuth for a scan where this happened. There is no override. If one is need, let Craig Walker know and it can be added. This function will mainly affect the Mauna Kea VLBA site which is often scheduled in scans before the source rises and which has long access times for the site techs doing tape changes.

For more information on how automatic tape handling works, see the AUTOMATIC TAPE ALLOCATION section.

The rest of this section concerns the use of AUTOTAPE for the Mark II system. It can be ignored by most (all?) current users.

For Mark II, AUTOTAPE requests automatic tape changes. Without it, tape changes must be explicitly specified. The value specified for AUTOTAPE, if there is one, should be a time. The default, if no argument is given, is 4:00:00, which is the recommended value. Specify a negative number to turn off tape changes and a positive number (a time) to change the default tape length. Tape changes are requested at intervals of the requested time beginning with the earliest start time of the whole schedule. If this would require a change in the middle of a scan, the change is moved to the start of the scan and all following changes are moved up. This is station dependent and so can cause non-simultaneous tape changes. The tape is assumed to be kept moving between scans.

The reference time for AUTOTAPE (Mark II use) can be altered with TPREF in the SCHED keyin file and with the TPTIME in the TAPEFILE. See Section 3.4 for information on TPTIME. TPREF is a time of the form hh:mm:ss. The automatic tape changes are requested at integral numbers of 4 hour intervals (for the recommended time) before or after TPREF. A date is not needed because 4 hours divides 24 hours evenly. Even if someone were to use the 2 or 6 hour VCR modes, those tape lengths still divide 24 hours evenly.

If TAPE is specified in a Mark II schedule for a scan while AUTOTAPE is set, a tape change will be requested and following tape changes will occur at 4 hour intervals from the time of the forced change. One specification of TAPE is usually all that is needed to get the tape changing sequence right if the earliest start time is a poor reference time.

For most Mark II projects, the default action of AUTOTAPE should be good. The major exceptions are projects that start on the half hour and tape changes are desired on the hour, and projects where it makes sense to have a short tape at the start on some stations to avoid short tape on other stations for which the source rises later. Both of these cases can be handled nicely with TPREF.

Note that for Mark II observations, if AUTOTAPE is turned off, no initial tape mount at the start of the project will be requested. This causes problems at some stations. It you insist on specifying all tape changes with TAPE, be sure to put one on the first scan for each station. This mode of setting tape changes is NOT recommended.

Argument: None or a number.

Options: Mark III or VLBA: Not 1 or 2 - SCHED sets tape direction, head position, and track assignments. =1 - VLBA on-line systems set above parameters. =2 - activate mid-scan automatic tape reversals. Mark II: No argument or 0 - do automatic tape changes at 4-hour intervals. -1 - turn off automatic tape changes. hh:mm:ss - time for modified tape length.

Default: Mark III or VLBA: SCHED controls tape.

Mark II: AUTOTAPE=4:00:00

Usage: Only one value used, the last.

Example: AUTOTAPE=2

AZCOLIM

AZCOLIM can be used to specify an increment to the azimuth collimation offset value used for pointing. This is added to the nominal position known by the on-line system for the particular receiver and to the value specified in the setup file. It is also added to the values used for offsets in pointing patterns and the value from the setup file.

Argument: An azimuth collimation offset in arc minutes.

Options: Any value.

Default: 0.0

Usage: Default to previous scan.

Example: AZCOLIM = 0.25

BW

BW specifies the bandwidths to use for the scan. One value can be given for each baseband channel. Any unset values will be set equal to the first so it is usually only necessary to specify one. Because of details of how the defaulting works, once more than one channel is explicitly set to a non-zero value (rather than just defaulting to the first), be sure to set that channel explicitly again, or it will retain the previous value. To get back to the default, explicitly set the bandwidth to zero. Note that, once upon a time, the sign of the bandwidth indicated the sideband, but that is no longer true.

Some (all?) of the digital backend systems, including the RDBE, cannot oversample. Plus the software job in SCHED to allow the sample rate to track the input bandwidth is looking a bit serious - the sample rate gets entangled with disk management etc. So, at least for now (written in Dec 2013), it will be necessary to make a new setup file to use a different bandwidth for most observations.

Note that new parameter CRDBW can be used to set the VLBA legacy system BBCs to a bandwidth when using the RDBE, which, with the PFB personality, cannot be set to narrow bandwidths. This is useful for reference pointing. Since the legacy system can oversample, CRDBW can be used without a new setup file.

Argument: Up to one real number for each channel. The number is the bandwidth in MHz.

Options: Need valid setting for the backend in use. For the VLBA legacy system, they were 0.0625, 0.125, 0.250, 0.5, 1, 2, 4, 8, or 16 MHz. For the digital backends, must be half the sample rate.

Default: Uses bandwidth from setup file.

Usage: Uses the most recent value specified.

Example: BW=2,2,2,2

CALTIME

CALTIME is the integration time in seconds for calibration data from the VLBA monitor system. This includes the total and switched powers used for system temperatures and also the pulse cals.

This is currently ignored for PCFS (VEX) systems.

Argument: A time in seconds for each scan.

Options: Any.

Default: 120

Usage: Uses the most recent value given.

Example: CALTIME=60

CENTERS

Triggers the use of multiple phase center processing on the DiFX correlator at least at the VLBA. In practice, this puts the list of phase centers in the .v2d file used in setting up correlation. Some day, it may put the list in the .vex file, if there is a standard for how to do that.

The argument of CENTERS must correspond to a list of names in the phase center groups listed after a PCENTERS command.

For now, there is no clear way to make the phase center list scan dependent, so specify the same name for each scan on the same source. This may not always be true, which is why the association of a phase center group with a pointing source is not done in the PCENTERS specifications.

For more information on multiple phase center processing, see that section about that topic.

Argument: A name of a group of phase centers. For now, must be the same for every scan on a given source.

Options: Any name of a group provided through PCENTERS

Default: None - don’t use multiple phase centers

Usage: Keeps value of previous scan.

Example: CENTERS=P1305

COMMENT

COMMENT is a string of up to 128 characters to be written on operator and telescope files just before the scan.

Argument: Text up to 128 characters.

Options: Any.

Default: Blank

Usage: Reverts to no comment if not specified for each scan.

Example: COMMENT=’ET, call home.’

CORAVG

CORAVG specifies the correlator averaging time in seconds.

For the DiFX software correlator on the VLBA, there are two options for how the specified average time is treated. If all average times are to contain exactly the same amount of data and the time tags are to match exactly the mean time of the data, the interval must be an integer number of FFTs and of short-term accumulator intervals. The default behavior of the correlator is to adjust the average time to the nearest option that fulfills these criteria. That may well not be a very “round” looking number. The adjusted time will usually deviate from the requested time by only a few percent, although in some extremes of narrow bandwidth and many spectral channels, it can be as high as a factor of SQRT(2). An alternative behavior is offered where the correlator takes the exact value specified. It then bins the scan into intervals of that length and averages any short term integrations that fall in a bin. The data are given the time tag of the center of the bin. This allows the user to choose any desired integration time exactly. But the amount of data contributing to each integration will vary, typically by one short-term accumulation. Also the true mean time of a data point will be offset from the time tag by a variable fraction of a short-term accumulation period. To invoke this behavior, put the word EXACT as a second argument to CORAVG (not case sensitive).

For the original Socorro VLBA hardware correlator, valid values are an integer N times the speed up factor times 0.131072 seconds. Round values such as 2, 4, 8 seconds etc may be specified and the nearest possible value will be used. This is what is expected from most users.

The correlator default is 2 seconds but, at most frequencies, more is probably ok most of the time. The longer the on-line averaging, the smaller the output data rates and the smaller the output data set.

Note the correlation parameters CORAVG, CORCHAN, CORPOL, CORTAPE, and CORSHIPn must be specified when the project will be correlated in Socorro and data are being recorded.

Argument: A real or integer number followed by a string of up to 8 characters

Options: Any, but see above for useful numbers. The string can be anything but only ”EXACT” will mean to do something different from the default.

Default: Must be given for processing in Socorro. Otherwise 2.0. The string can, and usually will, be omitted.

Usage: Only one value used — the last.

Example: CORAVG = 4, exact

CORAVG2

CORAVG2 specifies the alternate correlator averaging time in seconds. Valid values have the same restrictions as CORAVG. This will be the average time used on baselines to spacecraft (eg HALCA) processed on the VLBA correlator. It will typically be smaller than CORAVG.

Argument: A real or integer number followed by a string of up to 8 characters

Options: Any, but see CORAVG for useful numbers. The string can be anything, but only ”EXACT” will mean to do something different from the default.

Default: 0.0 — not used. The string can, and usually will, be omitted.

Usage: Only one value used — the last.

Example: CORAVG2 = 1

CORCHAN

CORCHAN(1) specifies the number of spectral channels per baseband channel (one polarization component) that the correlator will write. CORCHAN(2) specifies the number of channels to use in the internal FFT in the correlator.

The VLBA correlator (both old and new) will, by default, make 128 channel spectra which are then channel averaged on-line for continuum observations. The typical number of output channels for continuum observations is the greater of 16 or twice the baseband channel bandwidth in MHz. Over averaging can cause loss of amplitude due to “delay smearing” — the effect of large phase slopes across the channels going into an average. Delay offsets can either come from a large field of view or from errors in the a priori clocks used in processing. The twice bandwidth number is determined by the clocks and should represent a minimum.

Corrections for this effect are made in AIPS, but the corrections are probably not perfect. Besides delay smearing, over averaging can lead to SNR loss when bandpass calibration is done. This is because edge channels are discarded as part of bandpass calibration because of the frequency shifts required to adjust for the effects of the fringe rotators (Doppler effect, essentially).

For spectral line observations, the DiFX correlator can do a vary large number of channels - ”it’s just software”. But excessive numbers of channels lead to excessive output data rates and data set sizes. Up to 4096 channels per baseband channel are supported normally and up to 32768 channels can be supported if needed and justified. There are no special restrictions in full polarization mode. The 32768 limit is set by the AIPS postprocessing path. Requesting too many channels can cause the data sets to be so large as to be difficult to impossible to manage. Also, the combination of the average time, the number of channels, and the number of baselines must be such that the output data rate is less than 10 Mbyte/sec. That is per second of observe time. The data rate in bytes/sec is given APPROXIMATELY as

4 * Ns * (Ns + 1) * Nc * Nsp * P / Tavg

where Ns = number of stations Nc = number of (BaseBand) channels (1, 2, ... 16) Nsp = spectral resolution (8, 16, 32 ... 512) P = 2 for polarization, 1 for none Tavg = time average in seconds

The second argument can be used to specify the size of the FFT used in correlators such as DiFX. Normally that argument can be ignored and the FFT size will be set to the larger of 128 or the first argument. The ability to set that argument is provided in support of the multiple phase center capability added to DiFX in 2010. When using that option, the spectral resolution of the transforms done before the different phase centers are split must be high enough that the differential delays, which show up in the data as a phase slope in frequency, do not cause smearing. See the discussion of multiple phase center processing for more details advice.

Note the correlation parameters CORAVG, CORCHAN, CORPOL, CORTAPE, and CORSHIPn must be specified when the project will be correlated in Socorro and data are being recorded.

Argument: Two integer numbers, usually a power of 2.

Options: Any, but see above for useful numbers.

Default: The first argument must be specified for the VLBA correlator. Otherwise it defaults to 16. The second argument defaults 128

Usage: Only one pair of values is used — the last.

Example: CORCHAN = 32 or CORCHAN=16,2048

CORDFMT

Data correlated at the VLBA is always archived. Most has been converted to FITS files for use with astronomical processing software. Some is now being converted to the types of files produced on the Mark4 correlators (Haystack etc). Those data can be processed through the geodetic oriented programs including Fourfit. To request production of a Mark4 file, specify ”CORDFMT = MARK4”.

Argument: A character string of up to 8 characters.

Options: Any, should be FITS or MARK4.

Default: Defaults to ’FITS’

Usage: Only one value is used — the last.

Example: CORDFMT=MARK4 or CORCHAN=16,2048

CORNANT

CORNANT informs correlator operations of the number of stations scheduled. This helps determine when all logs and media are in and helps determine what the correlator load, both in terms of drives needed and output data rate, will be. See the discussion of CORCHAN for a formula to calculate the output data rate.

The default value for CORNANT is the number of antennas scheduled which will nearly always be correct. There should be no need to specify a number other than in some special, very strange cases such as when more antennas are scheduled than will be correlated.

Argument: An integer number.

Options: Any, but it should be the expected number of antennas.

Default: Number of antennas in schedule.

Usage: Only one value used — the last.

Example: CORNANT = 10

CORNOTE1, CORNOTE2, CORNOTE3, and CORNOTE4

CORNOTE1, CORNOTE2, CORNOTE3, and CORNOTE4 provide four text strings with which to pass information to correlator operations staff.

This can be used to alert correlator operations to special requirements such as multiple phase centers, special positions, non-constant processing parameters etc.

Argument: Each parameter is a string of up to 128 characters

Options: An address

Default: Blank

Usage: Only one of each used — the last.

Example: CORNOTE1 = ’Please run the FD tape backwards.’

CORPOL

CORPOL can be either “on” or “off”. If it is “on”, all polarizations (RR, LL, RL, and LR) will be done. If “off”, only the parallel hand polarizations (RR and LL) will be correlated. Requesting full polarization (“on”) reduces the maximum number of spectral channels per baseband channel available and increases the output data rate. However for continuum projects with modest average times and 16 or 32 channels, neither of these is of much concern and there is little harm in asking for full polarization processing. Perhaps the data will even be useful eventually.

Note the correlation parameters CORAVG, CORCHAN, CORPOL, CORTAPE, and CORSHIPn must be specified when the project will be correlated in Socorro and data are being recorded.

Argument: Any 3 characters.

Options: “on” or “off” are the useful values.

Default: Required for VLBA correlator, otherwise “on”.

Usage: Only one value used — the last.

Example: CORPOL = ’on’

CORREL

CORREL specifies the correlator to which VLBI media and logs should be sent. This is for the cover information. SCHED will abort if this parameter is not given unless this is a VLA only observation or a single dish observation (eg VLBA pointing). Allowed values are Socorro, VLBA, Haystack, Bonn, JIVE, Washington, USNO, Jpl, Bologna, Mitaka, Penticton, ASC, and Other (which should be followed by the name). The name is not case sensitive.

The first word of CORREL must be one of:

Socorro, VLBA, or VLBADIFX (VLBA DiFX software correlator)

Haystack,

Bonn (MPIfR DiFX correlator),

JIVE,

Washington or USNO,

LBA,

JPL,

Bologna,

Mitaka,

ASC (Astro Space Center - Moscow)

Penticton, or

Other

FXCORR (Original VLBA hardware correlator — no longer exists so SCHED will stop.)

Note the correlation parameters CORAVG, CORCHAN, CORPOL, CORTAPE, and CORSHIPn must be specified when the project will be correlated in Socorro and data are being recorded.

Argument: Text up to 62 characters.

Options: See list above for valid options.

Default: Blank which causes SCHED to abort.

Usage: Only one value used, the last.

Example: CORREL=VLBADIFX

CORSRCS

CORSRCS is a character string instructing the correlator staff where to get the source coordinates. STANDARD will imply to get them from the correlator catalog. This is an extensive list of sources based on USNO geodetic/astrometric solutions or, for sources for which VLBI positions are not known, from the VLA calibrator list. SCHEDULE will mean to get the positions from those used in this schedule. Other statements can be made - this information will be read by the correlator operations staff. If more room is needed, see the CORNOTE parameters.

Argument: Text of up to 64 characters.

Options: STANDARD and SCHEDULE are useful. Others can be used.

Default: STANDARD

Usage: Only one used — the last.

Example: CORSRCS = ’PI will provide before correlation.’

CORSHIP1, CORSHIP2, CORSHIP3, and CORSHIP4

CORSHIP1, CORSHIP2, CORSHIP3, and CORSHIP4 provide four character strings in which to specify the place to ship the correlator distribution .

Note the correlation parameters CORREL, CORAVG, CORCHAN, CORPOL, and CORSHIPn (if CORTAPE = DAT or EXABYTE) must be specified when the project will be correlated in Socorro and data are being recorded.

Argument: Each parameter is a string of up to 64 characters

Options: An address

Default: Blank — Which causes and abort if you requested shipable media.

Usage: Only one of each used — the last.

Example: CORSHIP1 = ’Phil Diamond’

CORSHIP2 = ’NRAO’

CORSHIP3 = ’P.O. Box O’

CORSHIP4 = ’Socorro, NM, 87801’

CORTAPE

CORTAPE specifies the type of media that should be used for the data distribution from the correlator. This must be FTP, DAT, DISK or NONE. FTP and NONE basically mean that the PI will pick up a disk copy of the data by means of a network copy (there is no effective difference between the two). EXABYTE was recently removed for lack of use, as 9TRACK was long ago. DAT will likely go soon. FLASH may get added some day, but not yet.

Argument: A string of up to 16 characters

Options: DAT, DISK, NONE, or FTP

Default: Blank, which causes and abort if data are being recorded.

Usage: Only one used — the last.

Example: CORTAPE = ’DISK’

CORWTFN

CORWTFN specifies the weighting function to be used on the VLBA correlator. The weighting function is applied by weighting the data points before they are sent to the FFT. Valid options are:

UNIFORM. No weights are applied. The data are used as is. The is the option that most users will want.

ZEROPAD. With this option, the input data for the FFTs are padded with zeros by a factor of two. This reduces the resolution of each spectral point. With the FX correlator, the frequency response of each spectral channel is sharper than with an XF correlator and this may not be what is desired for some spectral line observations. If so, ZEROPAD is a way to reduce the effect. Actually reproducing the frequency response of an XF correlator is possible in theory, but not with any of the available windowing functions. Note that ZEROPAD should not be used with the 1:4 fan out because that causes there to be no overlapping of FFTs so half the data are not used.

HANNING. With this option, a Hanning weighting is applied in before the FFT. This is done in the voltage (sample) domain and has the effect, after cross correlation, of applying a “Hanning squared” weighting on the final power spectra. This is probably not what the user wants.

QANNING. With this option, an approximation of a “root Hanning” weighting is applied to get close to the expected Hanning response in the power domain after correlation. It is only an approximation because the windowing function cannot have the negative values that would be required to do this exactly.

Eventually more options may be available.

Argument: Any text string of up to 16 characters

Options: UNIFORM and HANNING are the useful options.

Default: UNIFORM

Usage: Only one value used — the last.

Example: CORWTFN = ’HANNING’

COVERLET

COVERLET alerts the program that all lines after the next ’/’ and up the the occurrence of ’endcover’ and ’/’ on a line will be text that is to be transferred to the summary and operator schedule files (sch. files). This allows the PI to write a cover letter that will make it into files that the operators at at least some stations will see, hopefully eliminating the need to write a separate cover letter file. The amount of text is arbitrary and the line need only be shorter than 256 characters. Lines over about 80 characters may not look good in the output.

Note that the operators at some telescopes, including the VLBA, do not pay much attention to what is in the files. Cover letters of any type are not very effective. Your observation should be described well by the parameters that actually control telescope operations. Cover letters can be effective for observatories where some operations have to be done by hand.

The egglobal.key example shows the use of COVERLET.

Argument: none

Options: No argument required or useful.

Default: It will be assumed that there is no cover letter.

Usage: Only use preceding the cover letter input.

Example: COVERLET /

CRDBW

CRDBW is used in the main schedule when using either CRDFREQ or CRDDOP to set frequencies on the VLBA for the legacy system that are different from what is set for the RDBE. This is mainly to allow Doppler setting for masers for reference pointing, which is recommended at 86 GHz. See CRDFREQ for more details.

The channels should correspond to the channels in the current setup file because configuration information like the IF, first LO, sideband, etc will be taken from the setup. Only 8 channels will actually get used as, when the RDBE is in use, for bookkeeping ease, only one channel will be assigned to each bbc.

This parameter is equivalent to BW, but is only for use when using the RDBE but wanting different settings in the old system. It will be ignored except on the VLBA using the RDBE.

Any unset values will be set to the same as the first channel. It is good practice to set to 0.D0 when not in use, which may require setting all channels explicitly.

Argument: A list of bandwidths in MHz, one per channel.

Options: 0.0625, 0.125, 0.250, 0.5, 1, 2, 4, 8, or 16 MHz

Default: It is required if CRDFREQ or CRDDOP is used.

Usage: Retains the value from the previous scan if not set.

Example: CRDBW= 2.0, 2.0, 2.0, 2.0 /

CRDDOP and CRDNODOP

CRDDOP requests Doppler frequency setting for the VLBA legacy system BBCs. It is much like DOPPLER except that it should only affect the BBCs, not the RDBE. This is needed because the legacy system still controls the antenna pointing and does not have access to power levels from the RDBEs, which are controlled by the separate new control system. The total power data from the legacy BBCs are used to make the pointing measurements. See the discussion of CRDFREQ for more details about using the CRDxx parameters.

When using CRDDOP, you must also set CRDBW and one (and only one) of CRDCH1 or CRDSETCH.

As an alternative to requesting SCHED do Doppler calculations, you can force a specific frequency with CRDFREQ.

Specify CRDNODOP to turn off the BBC Doppler setting.

It is not recommended to attempt to use DOPPLER and CRDDOP at the same time, although it might work.

Argument: No argument

Options: None

Default: Do not use CRDDOP

Usage: Uses previous scan value if not specified

Example: CRDDOP

CRDLINE

CRDLINE allows the scheduler to insert an arbitrary string into the crd control files for VLBA antennas. It is intended to simplify the testing of new features by someone programming the on-line system. You almost certainly don’t want to use this parameter unless you are a VLBA programmer.

Argument: A character string of up to 80 characters.

Options: Any character string.

Default: Blank

Usage: One per scan. Remains at most recent value set.

Example: CRDLINE = ’This was requested by Walter’

CRDCH1

When setting parameters for the VLBA legacy hardware different from what is being set for the RDBE, parameters CRDFREQ, CRDDOP, CRDNCH, CRDBW, CRDSETCH, and CRDCH1 can be used. Many of the channel parameters are taken from the main setup. These include sideband, sample rate, IF channel etc. With the legacy system “CRD” parameters, only 4 channels (8 before early 2014) can be specified. With the RDBE_PFB, the number of setup channels is 16 while it can be up to 8 with the RDBE_DDC. By default, SCHED will try to spread the crd channels broadly over the setup channels and, in particular, will try to have at least one crd channel from each IF. CRDCH1 gives the opportunity to specify the first channel of a contiguous block of CRDNCH channels to use. Alternatively, one can use CRDSETCH to specify the template channels individually — probably the preferred option if not taking the default.

Argument: An integer

Options: Any integer 16 or less

Default: SCHED has an algorithm for distributing the channels broadly, making sure all IFs are represented.

Usage: One per scan. Defaults to last value.

Example: CHDCH1 = 5

CRDNCH

CRDNCH sets the number of channels to use on the legacy VLBA hardware (BBCs especially) when using the RDBE. The main reason for being concerned about the legacy hardware is that the power levels in the BBCs are used by the old control system to do reference pointing. See also CRDFREQ, CRDDOP, CRDBW, CRDCH1 for controls related to such reference pointing, especially with masers.

CRDNCH is a required parameter when CRDFREQ or CRDDOP are set.

When not using CRDFREQ or CRDDOP, CRDNCH will still set the number of channels used in the crd files controlling the BBCs. If CRDFREQ and CRDDOP are never used, CRDNCH will be set to lesser of 4 (the number of BBCs after April 2014) and the number of setup channels.

When CRDNCH is less than the number of channels in the main setup (typical if using the RDBE_PFB), then the alignment between the main setup channels and the legacy system channels can be set using CRDCH1

Argument: An integer

Options: Any integer 4 or less

Default: The lesser of NCHAN for the setup and 4 (number of BBCs after April 2014.)

Usage: One per scan. Defaults to last value.

Example: CHDNCH = 2

CRDFREQ

This parameter is equivalent to FREQ, but is only for use when using the RDBE but wanting different settings in the old system. It will be ignored except on the VLBA using the RDBE. The main use will be for 86 GHz observations using the PFB personality of the RDBE. With the PFB, the bandwidth per channel can only be 32 MHz and the frequencies are not flexible. To reference point on masers, it is necessary to use the legacy BBCs with narrower bandwidths and with frequencies that are not closely related to the main setup frequencies. Such settings can be determined from Doppler calculations using CRDDOP or set explicitly using CRDFREQ. Note that CRDBW must also be set if either of these options is used.

When CRDFREQ or CRDDOP is used, the resulting frequencies appear in the xxcrd.ss files that control the VLBA legacy system. They do not appear in the VEX file. As of this writing, they also don’t appear on the summary file, although changes can trigger specification of a new setup group that may not obviously be different from another group, if the only change is in the setup parameters.

Any unset values of CRDFREQ will be set to the same as the first channel’ value. It is good practice to set to 0.D0 when not in use, which may require setting all channels explicitly.

It is expected that this capability will be retired when the new control system takes over antenna pointing. At that time, any projects requiring reference pointing on masers will need to use the DDC personality of the RDBE, which allows fine tuning and narrow bandwidths.

Argument: A list of RF frequencies in MHz, one per channel.

Options: Any allowed RF frequency MHz

Default: Use values based on the setup file, with adjustments based on the limitations of the BBCs relative to the RDBE

Usage: Retains the value from the previous scan if not set.

Example: CRDFREQ= 43122.03, 43122.03 /

CRDSETCH

CRDSETCH is a list of setup file baseband channels to use for many channel dependent parameters such as IF channel, polarization, etc when setting up the channels for the VLBA legacy system. There can be as many entries as there are legacy system channels. As of early 2014 when 4 BBCs are being removed, that number is only 4. The effect is only on the crd files, not the Vex file.

This parameter can be very important when using the S/X system on the VLBA. The new VLBA control system will know that both S and X band receivers are in use and will set the hardware accordingly. Critically, it will or will not deploy the ellipsoidal reflector over the X band receiver. If the channels sent to the legacy control computer (the crd files) do not contain any S band channels, then that system will think this is an X band only observation. It has control of the subreflector so it will point the subreflector at the X band receiver. But that optical path is now blocked by the ellipsoid. So no source data will get through. However all other parameters like system temperature and pulse cal will look ok. You end up with hard-to-diagnose lack of fringes. This situation can, and has (guess how we know about this!) happened when there are many X band channels and only a few S band channels as is likely when using the RDBE_PFB.

Argument: A list of setup file channel numbers - up to 4. This can be changed on a scan basis

Options: Any channels

Default: If not used, and CRDNCH is not used, SCHED will make a reasonable selection, including making sure all IF channels are represented.

Usage: Defaults to previous scan

Example: CRDSETCH = 3,4,7,8

DATAPATH

This is an eVLBI control parameter. Be warned: eVLBI support is under development. The eVLBI parameters are GRABTO, GRABTIME, GRABGAP, and DATAPATH.

DATAPATH determines where the main data flow goes. It is meant to be used with systems like Mark5 that have an eVLBI (over the net) capability. The data can either go to disk as in normal observing DATAPATH=IN2DISK or it can go directly to the network DATAPATH=IN2NET.

When the data are sent to disk, there is an option to send small amounts over the network later for fringe checks and the like. That option is controlled by the GRAB... parameters.

Argument: Character string of up to 8 characters.

Options: IN2DISK for normal recording to disk or tape - the default. ’IN2NET’ for real time eVLBI with correlation or recording at a remote location.

Default: IN2DISK

Usage: A value for each scan. Defaults to previous scan.

Example: DATAPATH = ’IN2NET’

DAY

DAY is the day number of stop time of scan. Day 1 is the first day of the month specified with the MONTH parameter, which defaults to 1 so that DAY is the day of year. If LST was specified, DAY must be the (modified?) local sidereal day number for the reference station. These numbers are printed on the right side of VLA monthly schedules and are near 56800 in 1996.

Argument: Integer.

Options: Any.

Default: Required for first scan - no default.

Usage: Defaults to previous scan. Only need for first scan if using durations even if project crosses day boundary.

Example: DAY=135

DEBUG

DEBUG is a switch that turns on some debug printouts. It is unlikely to be useful to users, only to programmers.

DODOWN

Normally, SCHED eliminates stations for which the source is not up if they are using a disk recording system. DODOWN with no argument overrides that behavior and keeps stations in scans regardless. DODOWN can be set differently for each scan. Setting it to any non-zero value sets it to false (ie - go ahead and remove stations).

In the tape era, only VLBA stations were eliminated and only if AUTOTAPE was set to 2.

Without DODOWN, SCHED will also take a station out of a scan if the predicted slew time is such that the antenna will not reach the source before the scan end. However, it was found that this can prevent wraps from occurring in a timely manner during fast switching operations such as phase referencing, when one source needs the wrap a while before the other. Therefore, SCHED will not remove a station from a scan if mount type is ALTAZ and the requested azimuth slew is greater then 315 degrees. Such long azimuth slews would normally mean that a wrap is needed so getting it started is useful. There is no perfect algorithm to always do the right thing here so some though may be required by the PI if the behavior is odd. DODOWN is now scan dependent to help with dealing with odd behavior. Also explicitly including or excluding stations from the scan can be a strong tool for dealing with problems. Beware of special instructions when there is a chance that a program will be time shifted for dynamic scheduling. That will change when things like wraps need to happen.

Note that SCHED does not presume to tell the antenna what wrap to be on, mainly because there is no mechanism to do so with the VLBA. Some day this may change in which case SCHED can be more intelligent about what to do. For now all SCHED can do is control what scans are present and guess what the antenna will do.

Argument: None

Options: No argument

Default: Stations taken out of scans (DODOWN not zero)

Usage: One per scan. Defaults to previous value.

Example: DODOWN or DODOWN=-1

DOMKA

DOMKA (read DO-MKA) is a switch to request that, when observing with the RDBE and MARK5C, that a parallel MARK5A recording be made. It is expected to be used mainly for testing.

Argument: None

Options: No argument

Default: No Mark5A)

Usage: Only last used.

Example: DOMKA

DOPCAL

DOPCAL is an obsolete form of the parameter DOPPLER. It is no longer recommended because of possible confusion with DO PCAL.

DOPINCR

DOPINCR sets the frequency increments to use in setting frequencies using DOPPLER. The frequencies will be rounded to the nearest N * DOPINCR(1) + DOPINCR(2). The default for DOPINCR(1) when the RDBE is not in use is 10 kHz, the setting interval for the BBCs for the DBBC, LBA, and the legacy VLBA and Mark III/IV systems. For the RDBE_DDC option for DBE, the default is 15.625 kHz. For mixed legacy/DBBC/MARKIV and RDBE observations systems, the default is 250 kHz, the smallest value that is a multiple of both 10 kHz and 15.625 kHz. It is best not to use DOPPLER with the RDBE_PFB personality because of the tight tuning restrictions and the fact that the offset DOPINCR(2) depends on the LO setup. The ATCA LO is set in intervals of 1 MHz + 0.5 MHz.

The values are in kHz. A new value may be given for each scan, although usually a single value would be used for the whole experiment.

Argument: A number specifying a frequency in kHz.

Options: Any number.

Default: Depends on DBE — see text.

Usage: A value for each scan. Defaults to previous scan.

Example: DOPINCR = 1000,500 (appropriate for ATNF 20 GHz)

DOPPLER and NODOP

DOPPLER and NODOP control Doppler calculations for this scan. DOPPLER turns them on, NODOP turns them off. See Section 2.5 for details.

Note that channels assigned to the same BBC will be given the same frequency as the first channel on that BBC, no matter what velocities etc are given for the other channels. This will be the case when there are upper/lower sideband pairs. Their frequencies cannot be set independently. Because of the different sidebands, they will, however, cover different velocity ranges.

WARNING — if you are making extragalactic observations with high velocities (above about 1000 km/s), be sure to pay attention to the parameters VREF and VDEF in the source catalog. Extragalactic velocities are likely to be based on the “optical definition” which is not the SCHED default. Also, they are likely to be heliocentric, which is also not the SCHED default. In such a case, you would want to specify VDEF=O VREF=H. Note that you are also allowed to give z directly with VDEF=Z.

Argument: None.

Options: 0 or nothing to get Doppler calculations. A non-zero value will turn them off, but use of NODOP is a more convenient way to do the same thing.

Default: Don’t do Doppler calculations.

Usage: Reverts to previous scan.

Example: DOPPLER

DOSCANS

The user can specify optional scans on the ends of a project using the PREEMPT parameter. Those scans will be shown in the summary file .sum file, but will not be sent to the telescope control and others files (.vex, crd.xx, sch.xx, .oms and .flag files. To actually utilize those scans, or for that matter, any arbitrary subset of all the input scans, specify the range of desired output scans with DOSCANS. The arguments are the scan numbers of the first and last scans as they appear in the summary file.

It is intended that DOSCANS be used mainly by the VLBA scheduler while trying to put together dynamic schedules. It is often hard to find projects that mesh together exactly without leaving gaps. The PREEMPT=EXTRA and DOSCANS parameters are intended to let users provide productive observations to make during such otherwise unfilled gaps.

Note that DOSCANS can be used in conjunction with parameter WRAP24 to rotate the start point of full day schedules around the clock for more convenient dynamic scheduling.

Argument: Two integers

Options: Values that correspond to scan numbers in the .sum file

Default: zero - don’t use this scan restriction

Usage: One set of values used for the whole project

Example: DOSCANS = 154, 367

DOPSRC

DOPSRC is the name of the source for which the Doppler calculation should be done. This is allowed to be different from the source being observed to allow for observing continuum calibrators at the same frequency as the line source. If it is blank, the source being observed will be used. If it is not specified, the previous value will be used so it must be set to blank after use in earlier scans if it is desired to return to the original default.

A warning will be issued if SOURCE and DOPSRC are different and both have velocities specified (assumed to be line sources). This is a valid but unlikely observing style so it is not blocked. But too often it has been the result of ignoring the warning above about the defaulting behavior of DOPSRC.

Argument: A source name.

Options: Any source in the source catalogs.

Default: Blank - use SOURCE.

Usage: Reverts to previous scan. Can set to to return to default behavior.

Example: DOPSRC=’W3OH’

DOSTA

DOSTA tells SCHED to process only those stations whose names match the value given for DOSTA to as many characters as given for DOSTA. This is intended primarily for telescope friends who wish to rerun SCHED using the keyin file provided by the observer and who do not want output for all stations. Requiring a match only on the specified characters allows DOSTA=’VL’ to be specified to obtain all VLBA and VLA files. DOSTA affects the stations read for the current scan. Normally it would be specified among the first set of inputs and not changed. In this case, it will affect the whole schedule.

Argument: Text of up to 8 characters.

Options: Any station name or portion thereof.

Default: None

Usage: Defaults to previous scan.

Example: DOSTA=’VLBA’ makes all VLBA files.

DOVEX

DOVEX tells SCHED to write a VEX format output file. It is now the default so the parameter can be used to turn off writing of the VEX file. VEX is the format originally used by PCFS, the NASA/Goddard field system that controls EVN, geodetic and other stations. It is now used to control most correlators including the VLBA and other DifX correlators, the JIVE correlator and the geodetic correlators based on the Haystack design. VEX files will also eventually be used for control of the VLBA stations and the EVLA for VLBI. So a VEX file is required for essentially all VLBI observations now.

Argument: None.

Options: No argument required. If one given, DOVEX will be false.

Default: DOVEX will be true unless given a non-zero argument.

Usage: Only one value used — the last.

Example: DOVEX=-1 --- to turn VEX outputoff

DURation

The topic of controlling scan timing is discussed in detail in the Scan Times section.

DURation specifies the length of the current scan. Usually this is used instead of STOP. It is assumed to be a UT time interval unless LST was specified, in which case it was assumed to be an LST time interval. DWELL is a very similar parameter except that, with DURation, the scan starts GAP seconds (perhaps adjusted by the old parameter PRESCAN after the previous stop time while with DWELL, the scan will start at least GAP seconds after the previous stop time, but, if necessary, will wait longer to allow all antennas to reach the source.

Note that DUR and DWELL may be both be used in the same schedule, but cannot both be used for the same scan (that would not make sense). If either is used, the time specified overrides any previous specification of the scan length made with either parameter.

Once the nominal scan start time has been specified as above it can be adjusted further with the old, and mostly obsolete, parameter PRESCAN. Then the actual time that recording starts is adjusted further with MINPAUSE and PRESTART. PRESTART, MINPAUSE, and PRESCAN allow the user to start recording early to give the correlator a chance to synchronize before the start of good data. PRESTART can also be used to delay the scan start to be more sure it starts on good data — mostly useful with DWELL. These parameters also can help prevent short stoppages which used to cause problems with playback with tape systems. Adjusting the media start time should no longer be needed for correlators and recording systems currently in use (eg MARK5 and DiFX). See the descriptions of the parameters mentioned for more information. The SCHED defaults are generally reasonable so, if you are not an experienced user who wants to exercise fine control of recording management, don’t worry about these parameters.

The start and stop times reported in the summary and operator schedule files are the same for all stations. They take into account any adjustments made as a result of specifying PRESCAN, but do not take into account adjustments requested using MINPAUSE and PRESTART, since those can be station dependent. The time the media is started is reported in the sch.xx files under the heading ”TPStart”.

With the VLBA RDBE recording system and DiFX correlators, both recording and correlation start times ignore most of the efforts by SCHED to adjust recorder start times. They treat the data-good time as given as an offset from the start time in the $SCHED section of the VEX file as the time to start handling data. In the $SCHED section, there can be two start times, one commented out (line starts with “*”). The commented one is the nominal start time as seen in the SCHED summary file. The active one is what SCHED thinks is the media start time, usually the nominal start time minus PRESTART. Then on each station line, there are two offset times, one for the start and one for the stop. The start is greater of zero and the time when SCHED thinks the data will be good (on-source etc). That is what is used by the VLBA to start recording and DiFX to start correlation. So effectively, even when using duration scheduling, you are fairly likely to actually be using dwell scheduling.

See the Scan Times section for more information on the specification of scans.

Argument: A time in format hh:mm:ss, mm:ss, or ss.

Options: Any.

Default: Not used.

Usage: Defaults to previous scan. Overridden by DWELL.

Example: DUR=13:00

DWELL

The topic of controlling scan timing is discussed in detail in the Scan Times section.

DWELL is an alternate way to specify the duration of a scan. It is distinguished from DURation only in that the start time of the scan will be delayed until SCHED expects all antennas to be on source. Both the slew time, including acceleration, and the settling time from TSETTLE in the station catalog will be taken into account. The interval between scans will not be allowed to drop below MINSETUP from the antenna catalog to allow for finite scan setup times at some antennas. SCHED tries to arrange that useful data will be obtained for the full time specified by DWELL. With DURation, some of the specified time may not have good data because antennas are still slewing. Please see the description of DURation for a more complete discussion of the actions of these two parameters and their interactions with other parameters that influence scan times and recording activity.

As of Oct. 2010, DWELL has acquired second and third arguments. Argument 2 is the number of antennas to not wait for. Typically it will be a small integer like 1 or 2, but can be up to the number of antennas (not sure what that would do!). This should be useful if the there is a problem with long slews between pairs of sources near the zenith at one antenna. It would also be useful if you wish to let the less sensitive, but faster, antennas start observing once they are on source on the assumption that large, slow antennas might not need as much integration time. This is an issue with global observations or HSA. SUMITEM = EARLY can be used to inspect the results of the use of the second DWELL argument. For example, with that argument set to one, one antenna should have EARLY negative (got there after the start).

The third argument is a minimum time on source for the antennas that are not being waited for thanks to argument 2. The default zero for this argument allows the scan to end before the slow antenna(s) get to source. If a time is specified, then the scan will be extended until the last antenna gets that much time. In such a circumstances, the scan will still start when first group of antennas (other than those the second argument says not to wait for) get to source, so those antennas will get a longer scan than specified.

Please note that the model SCHED uses to calculate slew times is not especially sophisticated, especially in regard to the excess times beyond the slew that an antenna might take to start getting good data. It is adequate for most purposes, but, for example, it might not agree exactly with other programs such as the VLA scheduling program Observe. In such cases, the station specific program probably has the better answer. Also, for some systems, such as the VLA, SCHED is more interested in when VLBI data starts to be good which might be before a local correlator starts to get good data. As of Feb 2003, SCHED does take into account the time an antenna takes to accelerate to full slew speed, and should calculate slew times for short slews approximately correctly even if full speed is not reached.

Argument: A time in any allowed time format (hh:mm:ss, mm:ss, sss etc.), followed by an integer, and then another time.

Options: Any time. The integer should be smaller than the number of antennas. The second time is normally smaller than the first

Default: The duration of the scan must be specified with some combination of START, STOP, DURation, and DWELL. The number of antennas to not wait for defaults to zero as does the minimum time.

Usage: Reverts to previous scan. Overridden by DUR. The second and third arguments use the last setting in a DWELL command (not overridden by DUR)

Example: DWELL=110,1,60 (which is equivalent to DWELL=1:50,1,1:00). DWELL=110 is equivalent to DWELL=110,0 except that the latter will reset the second argument to zero if it had been something else while the former will not.

ELCOLIM

ELCOLIM can be used to specify an increment to the elevation collimation offset value used for pointing. This is added to the nominal position known by the on-line system for the particular receiver and to the value specified in the setup file. It is also added to the values used for offsets in pointing patterns and to any value from the setup file.

Argument: A elevation collimation offset in arc minutes.

Options: Any value.

Default: 0.0

Usage: Default to previous scan.

Example: ELCOLIM = 0.25

EMAIL

EMAIL gives the principal Investigator’s electronic mail address for the cover information. Use an Internet address where possible. Either of EMAIL or FAX must be provided if recording VLBI data. Both should be provided.

Argument: Text of up to 64 characters.

Options: Any.

Default: Blank

Usage: Only one value used, the last.

Example: EMAIL=cwalker@nrao.edu

EPHFILE

EPHFILE is used to specify the location of the JPL ephemeris file. This is only needed if SCHED is being asked to calculate the position of one or more objects using the ephemeris. This is done by including a recognized planet (or other body) name among the sources and not providing a source catalog entry for it (if there is a catalog entry, that is used instead).

The objects that SCHED understands are Mercury, Venus, Moon, Mars, Jupiter, Saturn, Uranus, Neptune, Pluto, and Sun. Topocentric positions and rates will be provided for VLBA antennas if one of these is specified. Geocentric positions along with rates and horizontal parallax are provided for the PM cards for the VLA. Note that SCHED does not understand how to specify moving objects to antennas that don’t use the VLA or VLBA control file types.

Under unix, environment variables may be used. For example, if SCHED is defined to mean /users/cwalker/sched, the base area under which all sched stuff is kept (substitute your local directory), then one can specify the ephemeris file with EPHFILE = $SCHED/catalogs/newfile.eph, if that were where it is (it isn’t!). Use the setenv (c or t shell) or export (korn shell) to set environment variables.

At the AOC, for now, the ephemeris file is on Brian Butler’s computer in the location shown in the example below. There is also a copy in the SCHED catalogs subdirectory.

Note that if planetary observations specified to stations that use the VEX file, the positions passed will not be of adequate quality for correlation and maybe not for pointing.

Argument: Text of up to 80 characters - a file name.

Options: Any valid file

Default: ’NONE’

Usage: Only one value used, the last.

Example: EPHFILE=/planets/ephemeris/JPLEPH.403.2

EXIT

EXIT terminates interactive input. It has the same effect as reaching the end of file when input to SCHED is from a keyin file. It should be issued after the “/” after the last scan and needs a “/” of its own. Any inputs issued with it will be ignored. Since SCHED is nearly always used with an input file, this parameter should rarely be used.

Argument: None which implies 0.D0.

Options: None.

Default: Not issued if non-zero.

Usage: Will terminate program so only can be used once.

Example: EXIT /

EXPT

EXPT is a description of the project for the listings.

Argument: Text up to 72 characters.

Options: Any.

Default: None.

Usage: Only one value used, the last.

Example: EXPT=’3C345 March 11, 1988 Mark II’

EXPCODE

EXPCODE is the project code from the Network or from NRAO. This is used as the first few characters of many file names.

Argument: Text of up to 8 characters. Best to use 6 or less. In fact, only 5 characters will be kept by much of the NRAO bookkeeping system.

Options: Any.

Default: ’NUG’

Usage: Only one value used, the last given.

Example: EXPCODE=BW005

FASTFOR

FASTFOR: is an obsolete parameter that only applies to tape.

FASTFOR: requests that the wide band tape (Mark III or VLBA) be run at the maximum forward speed during the prescan. Usually the intent is to get to the end of the tape prior to the start of the scan. If no argument is given, all stations will be issued with a fast forward instruction. If a list of stations is given, only those stations in the list will be fast forwarded. The station code may be used instead of the station name (not case sensitive).

Argument: None or a list of stations.

Options: None or a list of any stations in the scan. Not case sensitive.

Default: No fast forward unless there is insufficient room on the tape to complete the scan while recording in the current direction.

Usage: Reverts to no fast forward on next scan.

Example: FASTFOR or FASTFOR=VLBA_BR

FAX

FAX is the Principal Investigator’s FAX number for the cover information. Either an EMAIL address or FAX number must be provided when recording tape. Both should be provided.

Argument: Text of up to 64 characters.

Options: Any.

Default: Blank

Usage: Only one value used, the last.

Example: FAX=’+1-505-835-7027’

FOCOFF

FOCOFF gives the offsets in focus for a focus/rotation raster. See ROTPAT for details.

The values are offsets to be multiplied by the nominal offset for the band as understood by the program.

Argument: Up to 20 real numbers - the number of nominal recrements in focus for each position of a focus/rotation raster.

Options: Any number. 1.0 or 1.5 typically.

Default: 0.0

Usage: Only one set used per experiment.

Example: FOCOFF=0,-1,0,1,0

FOCUS

FOCUS is used in VLBA test observations to specify an increment to the focus value used for the subreflector position. This is added to the nominal position known by the on-line system for the particular receiver.

Note that the schedule requires focus values in mm while tsm reports focus achieved in cm.

This parameter might be used in astronomical observations if one wished to have the most optimum focus for a given frequency for a receiver that has a significant focus variation with frequency. The new (2012) 6cm receiver (4-8 GHz) has such a variation.

Argument: An incremental focus position in mm.

Options: Any incremental focus position.

Default: 0.0

Usage: Default to previous scan.

Example: FOCUS = 10.2

FREQ

FREQ specifies the LO sum observing frequencies for the baseband channels in MHz. When not specified, the last value specified is used. If 0 is specified, or FREQ is never given in the schedule, the default from the setup file is used. Any channels not specified will be set to the same frequency as the first. This defaulting only works when that channel was not previously set to an explicit value. The defaulting to the first channel is usually not what is desired. Whenever the frequencies change, a comment appears in the operator schedule file; the appropriate changes are made to the BBC frequencies for antennas using VLBA or VEX control files; and for snap files, dummy video converter commands are written without the correct video converter number and with the full LO sum (personnel at “snap” sites must edit in the correct video converter numbers and subtract the first LO). Since both the VLBA and Mark IV systems can only set frequencies to the nearest 10 kHz and the Mark III video converters are often used for Mark II projects, do not try to set a frequency that is not an even 10 kHz. Actually, SCHED will round to this value, or to DOPINCR, if it is given.

Argument: Up to 16 real numbers in MHz.

Options: Any.

Default: Use the setup file values.

Usage: Uses the last value specified.

Example: FREQ=22236.78,22238.78

FREQFILE

FREQFILE is used to specify the file containing the standard frequency setup information. This file is provided with SCHED and most users only need to point to it. If you want a setup that does not match one of the standards, SCHED will allow you to use one although it will issue warnings to remind you to be sure you know what you are doing.

On unix, an environment variable may be used.

For additions or corrections on EVN telescopes, contact Des Small at small@jive.nl.

A file name of up to 80 characters. Any. $SCHED/catalogs/freq_RDBE.dat Uses the last value specified. FREQFILE=/users/cwalker/sched/catalogs/freq.dat

FREQLIST

FREQLIST is used to request a table of information from the FREQFILE be written to frequencies.list. It takes two arguments giving a frequency range to be covered in the list (in MHz). If the second argument is omitted, it will be set equal to the first. This may be the only parameter given to SCHED — no others are needed. SCHED will quit after the table is made. This facility should be useful for determining which antennas can observe certain frequencies.

2 real numbers which are frequencies in MHz Any. Not used. No table written. Uses the last value specified. FREQLIST=4900,8600

GAP

The topic of controlling scan timing is discussed in detail in the Scan Times section.

GAP is the minimum gap in time between the previous stop time and the current nominal scan start time when scheduling with DURation or DWELL. For scheduling with DURation, it will be that time interval. For scheduling with DWELL, the interval might be longer if required for slews, but it will not be shorter. Note that PRESTART, PRESCAN (old, mostly obsolete parameter) and MINPAUSE are applied after the nominal scan times are established and could make the period during which the recording is stopped shorter than GAP. MINPAUSE is used to keep the recordings going through short gaps. Note that, if START is specified, GAP will be ignored.

If LST scheduling, GAP is a sidereal time, so it will be slightly shorter in UT (by about 1.0027).

For all types of scheduling, if the gap between scans is less than the value of MINPAUSE, the recordings are left running. The default MINPAUSE is 10 seconds for legacy systems and the DBBC. It is zero for the RDBE and WIDAR.

For Field System stations (most non-VLBA stations), gaps should be inserted to allow bank changes. The VLBA can switch between mounted disk banks (modules) on the fly, but the field systems need a pause in the data recording. Such gaps should be inserted every 22 minutes for recordings at 1 Gbps and proportionally less often at lower bit rates. These gaps need to be more than 10s long.

The PCFS software requires an interval of 36 seconds at tape reversals (not needed for disk) to produce a valid VEX file. A 40 second gap is required to change setup. Apart from these restrictions continuous recording is implied for gaps shorter than 10 seconds. In addition, users should realize that during continuous recording no calibration data is taken. Starting and stopping the recording can be forced using GAP or PRESCAN, or by using START times. GAP is probably the preferred mechanism. As of Feb. 2014, we are trying to determine what is the current minimum time for bank changes. It is actually likely to be less than 40 seconds.

There is an interaction between GAP and AUTOPEAK. Any specified GAP will be enforced for the interval between the input scans, but the inserted pointing scan can occur during that interval. Note, prior to Feb 2014, the gap was set to zero when pointing was inserted, so under some circumstances, the input scans could end up closer together than GAP.

Argument: A time in any approved time format (hh:mm:ss, mm:ss, sss etc.)

Options: Any time

Default: Zero.

Usage: Reverts to previous scan.

Example: GAP=2:00 (which is equivalent to gap 120).

GEOBACK

GEOBACK is a knob sticking out of the algorithm that selects sources for use in a geodetic segment. For the current source selection algorithm, it is not too useful and should be set to a value higher than the number of scans expected in the segment. The default is 100. For each new source, SCHED looks for which sources of those available would contribute the most to improving the rms of the SecZ parameters in a dummy fit. That dummy fit does not use all the sources in the segment so far, but rather is restricted to the last GEOBACK sources. Without that restriction, once all antennas are giving reasonable SecZ fits, no new source improves things much and the bias to short slews can lead to selection of sources that don’t really contribute much to the segment. By restricting the look-back, each new source must contribute to a fit. Since the algorithm was changed to concentrate on the antenna that did worst in after the previous source was added, rather than the RMS improvement, this restricted look-back capability has not been especially useful.

GEOBACK is also used to inhibit repeated use of any given source in a segment. Rather than prohibit repeats entirely, SCHED only prohibits repeats within each GEOBACK scans.

Argument: A number of scans to examine to help determine the best source to add to a geodetic block

Options: Any integer, but values above around 6 are highly recommended

Default: 100

Usage: Only one value used for the whole observation

Example: geoback=10

GEOHIEL

When selecting the initial sources (up to about 3/4 of the total) in a geodetic sequence, SCHED tries to find one that are especially low or high at some stations. GEOHIEL sets the lower bound of the region considered to be high. The related parameter GEOLOWEL sets the upper bound to the “low” region. The default GEOHIEL of 40 degrees has a SecZ of 1.55. Going higher increases slew times without all that much gain in SecZ.

Argument: Any real number

Options: This is an elevation in degrees. It should be between 0.0 and 90.0

Default: 40.0

Usage: Only one value used for the whole observation

Example: geohiel=53.4

GEOLOWEL

When selecting the initial sources (up to about 3/4 of the total) in a geodetic sequence, SCHED tries to find one that are especially low or high at some stations. GEOLOWEL sets the upper bound of the region considered to be low. OPMINEL sets the lower bound. The related parameter GEOHIEL sets the lower bound to the “high” region. The default GEOLOWEL of 23 degrees has a SecZ of 2.55 which differs by 1.0 from the SecZ of 40 degrees, the default for GEOHIEL.

Argument: Any real number

Options: This is an elevation in degrees. It should be between 0.0 and 90.0

Default: 23.0

Usage: Only one value used for the whole observation

Example: geolowel=20.0

GEOPRT

Specifying GEOPRT (no argument) or GEOPRT = 0 will cause the quality measure and the elevations at all sites for all scans in each trial geodetic sequence to be printed while trying to specify a new sequence. The output will go to sched.runlog. This can be a considerable amount of print and is only recommended when trying to understand what the algorithm is doing. If you are a glutton for punishment, use GEOPRT = 1 or even GEOPRT = 2 to cause a lot of information from the source choosing process to be spewed out. This is likely only useful when debugging the software and won’t make much sense without looking at the code to see what all the numbers are.

Argument: Either none, or a number of which 0, 1, 2 are the only useful ones

Options: No argument, 0, 1, 2

Default: -1 which, like anything below 0 means don’t do it

Usage: One value used from the schedule (the last)

Example: GEOPRT = 0 or simply GEOPRT

GEOSEG

Specifying GEOSEG flags a scan to be converted into a geodetic segment. See the section on insertion of geodetic segments for more details about this capability. The argument of GEOSEG is the total time for the geodetic segment. The duration of each scan in the segment is specified with DWELL. The scan to be converted should have a source specified to keep various checking routines happy, but it is not important what that source is, or even whether it is up. In the construction of the segment, it will be ignored.

Geodetic segments will likely need to be 30 to 40 minutes long to have good coverage at all antennas with multiple low elevation scans. They could be even longer if slow antennas are included. Note that not all antennas will be in all scans.

The sources used for the geodetic segments are specified with GEOSRCS.

Argument: Any time in seconds in the usual formats (hh:mm:ss, mm:ss, sss etc.)

Options: Any time

Default: zero - no geodetic segment to be constructed

Usage: Reverts to zero to avoid building successive segments.

Example: geoseg=30:00 for a 30 minute segment

GEOSLEW

When selecting sources for a geodetic segment, SCHED takes into account both the contribution to a fit for SecZ and the slew time. GEOSLEW controls the relative weight. A value of 1.0 means encourage slews shorter than about 1 minute. A larger value would encourage shorter slews. A larger value introduces a larger penalty for a long source and would encourage shorter slews.

Argument: Any real number

Options: Any number

Default: 1.0 - favors slews of around a minute

Usage: Only one value used for the schedule - the last

Example: geoslew=2.0

GEOSLOW

SCHED can leave stations out of a scan if they get there much later than most stations in order to help increase the number of scans in a geodetic sequence. If the source being checked is important for the slow station, it can be blocked from being selected at this pass so that it can be selected later when the slow station can get there in a more timely manner. The effect of doing this tends to be that the slow antennas get used in roughly every other scan (the slew calculation knows if an antenna has the full time of the previous scan to get where it is going). In the current algorithm, if the station arrives more than GEOSLOW seconds after the third to last antenna to get there, it can be left out. Average and median times have been tried as the reference, but there tend to be issues when not all antennas were in the previous scan.

Argument: Any real number - seconds.

Options: Any number

Default: 40.0

Usage: Only one value used for the schedule - the last

Example: geoslow=30.0

GEOSRCS

GEOSRCS is used to list the sources to consider for automatically inserted geodetic segments. It is array of source names, where the sources need to be in the SCHED source catalogs. Since the geodetic segments are best done with strong, compact calibrators with well known positions, all sources of interest are likely to be in one of the standard SCHED catalogs $SCHED/catalogs/sources.gsfc or $SCHED/catalogs/sources.petrov. Note that some people use an odd source name convention that is the J2000 name but truncated at 8 characters (some software doesn’t like more). As of this writing, those names are only included as aliases in the GSFC catalog. For more information about automatic insertion of geodetic segments, see the section on insertion of geodetic segments and the description of the parameter GEOSEG.

The list in the sample below is the recommended set that is the 295 defining sources of the ICRF2. This would be a good list to use and is the list actually active in the example egdelzn.key, alhough that example shows a couple of other possible lists.

Sample input to SCHED:

! ==========================================================  
! =============  Sources for geodetic segments  ============  
! ==========================================================  
geosrcs=’0002-478’,’0007+106’,’0008-264’,’0010+405’,’0013-005’,’0016+731’,  
        ’0019+058’,’0035+413’,’0048-097’,’0048-427’,’0059+581’,’0104-408’,  
        ’0107-610’,’0109+224’,’0110+495’,’0116-219’,’0119+115’,’0131-522’,  
        ’0133+476’,’0134+311’,’0138-097’,’0151+474’,’0159+723’,’0202+319’,  
        ’0215+015’,’0221+067’,’0230-790’,’0229+131’,’0234-301’,’0235-618’,  
        ’0234+285’,’0237-027’,’0300+470’,’0302-623’,’0302+625’,’0306+102’,  
        ’0308-611’,’0307+380’,’0309+411’,’0322+222’,’0332-403’,’0334-546’,  
        ’0342+147’,’0346-279’,’0358+210’,’0402-362’,’0403-132’,’0405-385’,  
        ’0414-189’,’0420-014’,’0422+004’,’0426+273’,’0430+289’,’0437-454’,  
        ’0440+345’,’0446+112’,’0454-810’,’0454-234’,’0458-020’,’0458+138’,  
        ’0506-612’,’0454+844’,’0506+101’,’0507+179’,’0516-621’,’0515+208’,  
        ’0522-611’,’0524-460’,’0524-485’,’0524+034’,’0529+483’,’0534-611’,  
        ’0534-340’,’0537-441’,’0536+145’,’0537-286’,’0544+273’,’0549-575’,  
        ’0552+398’,’0556+238’,’0600+177’,’0642+449’,’0646-306’,’0648-165’,  
        ’0656+082’,’0657+172’,’0707+476’,’0716+714’,’0722+145’,’0718+792’,  
        ’0727-115’,’0736+017’,’0738+491’,’0743-006’,’0743+259’,’0745+241’,  
        ’0748+126’,’0759+183’,’0800+618’,’0805+046’,’0804+499’,’0805+410’,  
        ’0808+019’,’0812+367’,’0814+425’,’0823+033’,’0827+243’,’0834-201’,  
        ’0851+202’,’0854-108’,’0912+029’,’0920-397’,’0920+390’,’0925-203’,  
        ’0949+354’,’0955+476’,’0955+326’,’0954+658’,’1004-500’,’1012+232’,  
        ’1013+054’,’1014+615’,’1015+359’,’1022-665’,’1022+194’,’1030+415’,  
        ’1030+074’,’1034-374’,’1034-293’,’1038+52A’,’1039+811’,’1042+071’,  
        ’1045-188’,’1049+215’,’1053+815’,’1055+018’,’1101-536’,’1101+384’,  
        ’1111+149’,’1123+264’,’1124-186’,’1128+385’,’1130+009’,’1133-032’,  
        ’1143-696’,’1144+402’,’1144-379’,’1145-071’,’1147+245’,’1149-084’,  
        ’1156-663’,’1156+295’,’1213-172’,’1215+303’,’1219+044’,’1221+809’,  
        ’1226+373’,’1236+077’,’1240+381’,’1243-072’,’1244-255’,’1252+119’,  
        ’1251-713’,’1300+580’,’1308+328’,’1313-333’,’1324+224’,’1325-558’,  
        ’1334-127’,’1342+662’,’1342+663’,’1349-439’,’1351-018’,’1354-152’,  
        ’1357+769’,’1406-076’,’1418+546’,’1417+385’,’1420-679’,’1423+146’,  
        ’1424-418’,’1432+200’,’1443-162’,’1448-648’,’1451-400’,’1456+044’,  
        ’1459+480’,’1502+106’,’1502+036’,’1504+377’,’1508+572’,’1510-089’,  
        ’1511-100’,’1514+197’,’1520+437’,’1519-273’,’1546+027’,’1548+056’,  
        ’1555+001’,’1554-643’,’1557+032’,’1604-333’,’1606+106’,’1611-710’,  
        ’1614+051’,’1617+229’,’1619-680’,’1622-253’,’1624-617’,’1637+574’,  
        ’1638+398’,’1639+230’,’1642+690’,’1633-810’,’1657-261’,’1657-562’,  
        ’1659-621’,’1705+018’,’1706-174’,’1717+178’,’1726+455’,’1730-130’,  
        ’1725-795’,’1732+389’,’1738+499’,’1738+476’,’1741-038’,’1743+173’,  
        ’1745+624’,’1749+096’,’1751+288’,’1754+155’,’1758+388’,’1803+784’,  
        ’1800+440’,’1758-651’,’1806-458’,’1815-553’,’1823+689’,’1823+568’,  
        ’1824-582’,’1831-711’,’1842+681’,’1846+322’,’1849+670’,’1908-201’,  
        ’1920-211’,’1921-293’,’1925-610’,’1929+226’,’1933-400’,’1936-155’,  
        ’1935-692’,’1954+513’,’1954-388’,’1958-179’,’2000+472’,’2002-375’,  
        ’2008-159’,’2029+121’,’2052-474’,’2059+034’,’2106+143’,’2106-413’,  
        ’2113+293’,’2123-463’,’2126-158’,’2131-021’,’2136+141’,’2142-758’,  
        ’2150+173’,’2204-540’,’2209+236’,’2220-351’,’2223-052’,’2227-088’,  
        ’2229+695’,’2232-488’,’2236-572’,’2244-372’,’2245-328’,’2250+194’,  
        ’2254+074’,’2255-282’,’2300-683’,’2318+049’,’2326-477’,’2333-415’,  
        ’2344-514’,’2351-154’,’2353-686’,’2355-534’,’2355-106’,’2356+385’,  
        ’2357-318’  

Argument: Up to 400 source names. That can be adjusted if more are needed

Options: Any valid source names.

Default: No sources

Usage: One list used, the last

Example: See above text

GEOSREP

SCHED resists scheduling a given source more than once in a geodetic sequence. But sometimes it is worth doing that when there are limited low elevation options. GEOSREP can be used to set the minimum number of scans after an observation in a geodetic block that a source can be observed again. The default is high enough to normally prevent repeats. A lower value will allow repeats.

Argument: Any integer.

Options: Any, although negative and zero don’t make much sense.

Default: 40.0

Usage: Only one value used for the schedule - the last

Example: geosrep=6

GEOTRIES

The selection of sources for a geodetic segment is based on constructing several possible geodetic sequences and choosing the best. The first few selected sources for each tested segment are chosen randomly from among those that can contribute to the low elevation scans at at least one station. After those, the program chooses the source that best complements those chosen so far in terms of improving the quality measure without excessive slewing. Parameter GEOTRIES sets the number of trial segments to construct and test. The algorithm for making segments comes up with reasonable ones most of the time, so it is not generally necessary to test very many. The algorithm is also moderately slow which will encourage not testing too many. The default is 10 which seems reasonable.

Argument: Any integer 1 or above.

Options: Any

Default: 10

Usage: One value used, the last

Example: GEOTRIES=25

Argument: Either none, or a number of which 0 and 1 are the only useful ones

Options: No argument, 0, or 1

Default: -1 which, like anything besides 0 or 1, means don’t do it

Usage: One value used from the schedule (the last)

Example: GEOPRT = 0 or simply GEOPRT

GRABTO

This is an eVLBI control parameter. Be warned: eVLBI support is under development. The eVLBI parameters are GRABTO, GRABTIME, GRABGAP, and DATAPATH.

GRABTO is used to help control sending of small amounts of previously recorded data over the net. That process happens after the scan of interest, which was recorded normally. The data can either be copied first to the system disk, then transferred later by, for example, ftp or some other protocol GRABTO=FILE. Or the data can be sent directly to the net GRABTO=NET from the VLBI disks. It seems that GRABTO=NET is not valid for systems controlled by the Field System (eg MarkIV and variants).

This is different from the real time transfer controlled by DATAPATH.

If GRABTO is NONE, which is the default, no data will be written and the other GRAB.. parameters will be ignored.

Note that GRABTIME determines what segment of data is sent. GRABGAP determines what amount of time needs to be set aside to grab the data from the VLBI disk (ftp transfer can happen during the next scan).

Argument: Character string of up to 4 characters.

Options: NET for direct transfer to external network. FILE for transfer to the control computer system disk. NONE Do not transfer the data anywhere.

Default: NONE

Usage: A value for each scan. Defaults to previous scan. Be sure to set back to ’NONE’ after a grab scan.

Example: GRABTO = ’FILE’

GRABTIME

This is an eVLBI control parameter. Be warned: eVLBI support is under development. The eVLBI parameters are GRABTO, GRABTIME, GRABGAP, and DATAPATH.

GRABTIME determines which part of a scan will be used for eVLBI. There are 2 arguments. The first gives the duration in seconds of the data to be sent. The second argument gives the seconds before the end of the current scan that the grabbed data will end. Thus the data to be sent are from the interval from GRABTIME(1) + GRABTIME(2) to GRABTIME(2) seconds before the end of the scan.

Argument: Two real numbers — times in seconds.

Options: Any times.

Default: 30,0. Which means transfer the last 30 seconds of the scan

Usage: Values for each scan. Defaults to previous scan.

Example: GRABTIME = 30,0

GRABGAP

This is an eVLBI control parameter. Be warned: eVLBI support is under development. The eVLBI parameters are GRABTO, GRABTIME, GRABGAP, and DATAPATH.

GRABGAP specifies how much time will be needed after the scan to transfer the data. This will initially just be used for checking, and maybe for some optimization functions. Eventually it may have other uses.

Argument: Two real number — time in seconds.

Options: Any time.

Default: 5.0 + GRABTIME(1)*bitrate/110Mbps

Usage: Value for each scan. Defaults to previous scan.

Example: GRABGAP = 90

GRIDMIN

GRIDMIN is the inner radius of the grid used for UV coverage optimization. It is in the units of the UV plot. See the section on Configuration Studies for details. This is only used when OBSTYPE=CONFIG.

Argument: Any number, typically a value similar to the array’s shortest baseline.

Options: Any value.

Default: 25.0 (km for NMA studies)

Usage: Only last one used

Example: GRIDMIN = 10.0

GRIDMAX

GRIDMAX is the outer radius of the grid used for UV coverage optimization. It is in the units of the UV plot. See the section on Configuration Studies for details. This is only used when OBSTYPE=CONFIG.

Argument: Any number, typically a value similar to the array’s shortest baseline.

Options: Any value.

Default: 250.0 (km for NMA studies)

Usage: Only last one used

Example: GRIDMAX = 350.0

GRIDMEAS

GRIDMEAS is used to choose between quality measures to use when rating arrays using the UV coverage on the grid specified with the other “GRID” parameters. The options are COUNT, which simply counts the number of sampled cells, and RMS, which determines the RMS of the number of samples per cell.

Argument: COUNT or RMS

Options: Only one of the above two options

Default: COUNT

Usage: Only last value used

Example: GRIDMEAS = ’COUNT’

GRIDNR

GRIDNR is the number of radial cells in the grid used for UV coverage optimization. See the section on Configuration Studies for details. This is only used when OBSTYPE=CONFIG.

Argument: Any integer. About 40 can be a reasonable choice.

Options: Any value. (non-integers will be truncated.)

Default: 20

Usage: Only last one used

Example: GRIDNR = 40

GRIDNT

GRIDNT is the number of azimuthal cells in the grid used for UV coverage optimization. See the section on Configuration Studies for details. This is only used when OBSTYPE=CONFIG.

Argument: Any integer. About 72 can be a reasonable choice.

Options: Any value. Non-integers will be truncated.

Default: 36

Usage: Only last one used

Example: GRIDNT = 72

GRIDSTEP

When doing configuration studies, if key S is pressed, SCHED will calculate the array quality measure for points on a grid in latitude and longitude centered on the first highlighted (red) station. It is best to only highlight one. Then labeled contours will be plotted over the region of the calculation. Note that the contours are not cleared until the uvcoverages are plotted, so you can end up with several. The contours are reploted (including to an output file) until some action like altering a any station’s selection status or moving a station is done. The spacing of grid points in latitude and longitude for calculating the quality is given in arcminutes by GRIDSTEP.

Argument: A number in arcminutes of latitude and longitude for the spacing of station locations used to make a contour map of quality measure

Options: Any real number

Default: 3.0 - three arcminutes

Usage: Only last one used

Example: GRIDSTEP = 6.0

GRIDVLA

When doing configuration studies, only use baselines to the VLA to calculate the quality measure. This is useful for the NMA which will have large swatches of baselines to the VLA. Those swatches dominate the sensitivity.

Argument: No argument to set. Any non-zero number will unset.

Options: Any number, but none needed (logical)

Default: Not set (will use baselines to VLA antennas)

Usage: Only last one used

Example: GRIDVLA

GRIDW0

GRIDW0 is the approximate radius of the transition from linear to logarithmic radial grid sizes in the grid used for UV coverage optimization. It is in the units of the UV plot. See the section on Configuration Studies for details. This is only used when OBSTYPE=CONFIG.

Argument: Any number, typically a value at about 0.1 to 0.3 of the array’s longest baselines

Options: Any value.

Default: 0.0 (results in a pure logarithmic grid)

Usage: Only last one used

Example: GRIDW0 = 45.0

GROUP

SCHED has the ability to accept loops through scans. The two parameters that allow this are GROUP and REPEAT. They should be specified along with the parameters of the first scan in the loop. GROUP specifies the number of scans to be involved in a loop. REPEAT specifies how many times to go around the loop. Any start or stop times specified for the scans of the loop will only apply to the first pass. DURation or DWELL should be used to set the scan lengths.

Argument: Integer.

Options: Any.

Default: Not used.

Usage: Reverts to not being used if not specified for a scan.

Example: GROUP=2

HIGROUP

HIGROUP is used in conjunction with OPTMODE = ’HIGHEL’. If HIGROUP is set to greater than 1 for a scan while PTMODE = ’HIGHEL’, a number of scans specified by HIGROUP, including the one where it is specified, are checked for elevation. The single scan with the highest elevation is used. This aids in picking sources for calibrators, pointing scans etc what are best for a schedule whose run time might be set just before the observations.

Argument: Integer.

Options: Any.

Default: Not used.

Usage: Reverts to not grouping scans.

Example: HIGROUP=6

IATUTC

Obsolete parameter now that the VLA is no longer using observe decks.

IATUTC sets the value of IAT-UTC. This is about 30 seconds now. This is only used if “//PM” cards are needed for the VLA since the zero-offset epoch must then be specified in IAT. SCHED does not use IAT for anything else. If not specified, the default is the value from the SLA library which should be ok, as long as that routine is maintained.

Argument: An integer number of seconds.

Options: Any integer - should be correct value.

Default: Value from SLA_DAT, which should be correct.

Usage: Only one value accepted, the last.

Example: IATUTC=29

INTENTs

INTENTs is used to provide a series of text strings that give guidance to various stages of data handling. They can be directives to telescopes to, for example, do active phasing at the VLA or hold the previous phase. They could be used by the correlator. Or they can be used to tell pipeline processing that a scan is to be used for one or more specific types of calibration. For now, the intents are written to the VEX file as comments with the scans.

The arguments of INTENTs are up to 25 strings of up to 80 characters each. Note that each string should be in quotes and they should be separated by commas. If the line ends with a comma, the next line can be used for the next string. If no INTENTs are given, they default to the previous scan. If any are given, they all return to blank unless given again again. If NONE is specified, all intents are cleared.

SCHED does not parse most INTENTs. But some, especially related to the VLA phasing, are recognized and appropriate actions are taken.

An intent may be made to target a specific antenna by starting with the station name followed by a colon. Use the same station name as used in the station catalog. If no station name is given, the INTENTs will be assumed to apply to all stations for which it is meaningful. An example line with a station might address asking the VLA to phase but not some other interferometer with: INTENT = ’VLA:AUTOPHASE_DETERMINE’.

Some established values of INTENTs in the VLA environment are listed here. Also some requested for other instruments are listed. Most will not be used in VLBI schedules. A VLBI specific list has not been generated. Of interest for the VLA are DETERMINE_AUTOPHASE and DETERMINE_OFFSET_POINTING.

OBSERVE_TARGET

CALIBRATE_BANDPASS

CALIBRATE_FLUX_DENSITY_SCALE

CALIBRATE_COMPLEX_GAIN

CALIBRATE_POLARIZATION_ANGLE

CALIBRATE_POLARIZATION_LEAKAGE

CALIBRATE_ABSOLUTE_POSITION

CALIBRATE_OFFSET_POINTING

DETERMINE_AUTOPHASE

DETERMINE_RFI

CALIBRATE_DELAY

FIND_FRINGE

DETERMINE_ANTENNA_GLOBAL_POINTING_MODEL

MAP_ANTENNA_SURFACE

CALIBRATE_FOCUS

DETERMINE_SINGLE_DISH_POINTING

DETERMINE_OPACITY_TIPPING_STYLE

OBSERVE_PULSAR

TIME_PULSAR

SetAtnGain

OTHER

This above list is from VLA documentation. For VLBI, the following are also used, although the preferred method of creating them is through the VLAMODE and VLAPEAK parameters. SCHED will not allow mixing methods of specifying these aspects of the observing.

AUTOPHASE_DETERMINE to apply the phasing offsets.

AUTOPHASE_APPLY to apply the phasing offsets.

AUTOPHASE_OFF to not apply any phasing offsets.

REFERENCE_POINTING_DETERMINE

REFERENCE_POINTING_ADJUST

REFERENCE_POINTING_APPLY

REFERENCE_POINTING_OFF

Argument: Up to 25 character strings of up to 80 characters each. Can use separate lines as long as the preceding line ends in a comma.

Options: Any strings. ’NONE’ clears all INTENTs’

Default: Blank

Usage: All INTENTs keep the last value if none are specified. If any are specified, all are initialized to blank, and must be respecified if still desired.

Example: intent = ’DETERMINE_AUTOPHASE’, ’CALIBRATE_BANDPASS’ or intent=VLA:SetAtnGain

LINEINIT

LINEINIT indicates that the next few keyin input groups are rest frequency specifications for spectral line observations. See Section 2.5 for details. LINEINIT should not be mixed with other indicaters of in-stream data such as SRCCAT, STACAT, SETINIT, or TAPEINI. If LINEINIT is found, the end of the input group (everything up to the “/”) is not considered the end of inputs for this file. The next inputs after the line data are entered will continue to apply to the current file (usually the first).

Argument: None.

Options: None.

Default: Not set.

Usage: Should only be given once in schedule.

Example: LINEINIT /

LINENAME

LINENAME gives the name of the rest frequency group to use for this scan. The rest frequencies and names are specified in the LINEINIT input. See Section 2.5 for details.

Argument: A name of up to 8 characters.

Options: Must be one of the names in the LINEINIT input.

Default: Must use if DOPPLER set.

Usage: Reverts to previous scan.

Example: LINENAME=’OH1665’

LINEPG

LINEPG is the number of lines on a page for the operator schedule files and summary files.

Argument: Integer.

Options: Any.

Default: 55

Usage: Only one value used.

Example: LINEPG=60

LOCFILE

LOCFILE gives the name of an auxillary file to the stations catalog that can contain the station positions. All parameters that can be specified in the LOCFILE can be specified directly in the station catalog and are documented along with that catalog. The station locations used in the default catalogs are from the VLBA correlator data base and are maintained in a very different way from the rest of the information in the station catalog, so it is convenient to have them in a separate file. If a user is making their own catalog, they could put all the information in the station catalog as indeed they must if putting the information into the main schedule through STACAT.

LOCFILE defaults to the standard file distributed with SCHED. If the file is not found, a complaint will only be generated if a stations in the station catalog is missing a position.

Only a subset of the stations catalog parameters can be put in the LOCFILE. They are X, Y, Z, DXDT, DYDT, DZDT, EPOCH, AXISTYPE, and AXISOFF. All other station information must be in the main stations catalog. In addition to these parameters, a catalog version number (VERSION), a station name (DBNAME), and a station code (DBCODE), that might be different from those used in the main stations catalog, should be included. The desired locations catalog entry is identified by giving a matching DBNAME or DBCODE in the main stations catalog to point to the locations catalog entry. The use of different names and codes is an artifact of the use of position information from the geodetic groups which use different station names from those typically used in astronomy. Also the locations file generally contains a separate entry for each pad of an interferometer such as the VLA which is not the case for the stations catalog.

Argument: A file name of up to 80 characters.

Options: Any valid file name or none.

Default: $SCHED/catalogs/locations.dat

Usage: Only specify once.

Example: LOCFILE=’/users/cwalker/sched/locations.dat’

LST

LST causes SCHED to assume that all input times are in local sidereal time. If no argument is given, the “local” refers to the VLA. Otherwise, a station name can be given to allow scheduling in lst for some other station.

When LST is specified, there are two ways to specify the date. DAY can be used to specify the (modified?) local sidereal day number as found on the VLA monthly schedules. If this is done, YEAR and MONTH are ignored. SCHED senses this situation by testing for a day number larger than the length of a year. The other option is to specify the calendar date in the usual way ( YEAR, MONTH, DAY). In this case, SCHED will figure out when on that calendar day the local sidereal time specified for a scan occurs. With this option there is a period of a bit less than 4 minutes each day when the specification is ambiguous (sidereal days are shorter than UT days). If that situation is encountered, SCHED will abort with a request to choose the desired local sidereal day — the options will be shown.

This parameter was originally intended mainly for VLA-only scheduling. But it is now also used for dynamic scheduling on the VLBA.

When LST is selected, most times are sidereal times or intervals. These include START, STOP, DURation, and DWELL, but not PRESCAN, MINPAUSE, or PRESTART.

Argument: Text of up to 8 characters giving the station name.

Options: Any.

Default: Not used if not given. ’VLA’ if given without argument.

Usage: Only one value used.

Example: LST=’VLBA_PT’

MAPLIM

MAPLIM is used to provide the longitude and latitude limits for the plot that is made when ( OBSTYPE is set to CONFIG and there are more than one source. This is a special mode mainly for array configuration studies. The 4 values are the longitude minimum and maximum followed by the latitude minimum and maximum, all in degrees. The system is such that North America is at positive longitudes, which is backwards from some schemes.

Argument: Four numbers.

Options: Any.

Default: Use numbers appropriate for NMA configuration study.

Usage: Only one value used.

Example: MAPLIM=80.0, 140.0, 15.0, 50.0

MINPAUSE

MINPAUSE is used to specify the minimum time a recording will be stopped between scans. Its effects are basically ignored by the wideband systems (RDBE, WIDAR with MARK5C recording) on the VLBA, VLA GBT, EB_VLBA and perhaps others so users of those systems can ignore the parameter, taking the default of zero.

The topic of controlling scan timing is discussed in detail in the Scan Times section.

If the interval between scans is shorter than the minimum specified with MINPAUSE, the recording will be be kept going between the scans. The need to prevent the recording from stopping for a short interval was most pronounced with tapes which took several seconds to accelerate and decelerate. With disks, that is not an issue so the only reason would be if there is a finite time to get the recording organized and the playback synchronized. Those are issues, at a low level with the Mark5A systems, but not with the Mark5C, which is in use and will become the dominant recording during 2013. With Mark5C, MINPAUSE should be set to a very small value or zero. Zero is the default for all systems except the legacy VLBA DAR and anything controlled by the Field System (may change for the DBBC). For the exceptions, 10 seconds is used.

For the VLA and sites with the VLBA control system, the recordings are started at the data-good time as reflected in the individual station lines of the VEX file. Those times account for any antenna slew and the additional time requested through TSETTLE and other such parameter in the station catalog. MINPAUSE only affects the media start time which is the nominal start time minus PRESTART, not the data good time, so it is basically ignored for such VLBA and VLA

MINPAUSE can be specified for each scan, but usually will be set to one value for the whole schedule. If the media start of a scan is less than MINPAUSE (seconds) from the end of the last recording scan, the recording will be left running between the scans. This action is station dependent — different stations can have the recording started at different times except when writing a VEX file, in which case simultaneity is enforced. The nominal start time of the scan as displayed in the summary is not affected by MINPAUSE. You can use the option TPSTART in the SUMITEM list to display in the summary how long before the scan start time the recording starts. The recording start time is also given in the sch file.

MINPAUSE is mainly used now to prevent excessive recording scans on the Mark5A system. The system does not allow more than 1024 data scans on the disks. There is one scan for each period during which the recording does not stop, regardless of the number of source scans during that period. This limitation can be an issue with large disk packs and fast-switching phase-referencing projects. The default value is meant to prevent recording stops during fast switching.

While too many recording scans are a problem, so are too few. If something goes wrong with playback, the correlators cannot recover until the start of the next recording scan. Thus it is not wise to have recording scans more than about an hour long. Note that the MarkIV systems will not stop the recording for gaps of less than 10 seconds so a gap inserted to break a recording scan should be longer than that.

Short recorder stoppages could cause problems for playback in the era of tapes. Every time the recording stopped, it must be resynced, which takes 10-20 seconds for the old VLBA hardware correlator. This is not much of an issue for the DiFX software correlator or the MarkIV correlators.

There are a variety of ways to prevent recordings from being stopped between scans. The simplest is to schedule using DUR or explicit times with no specification of an interval between scans. In such cases, SCHED will not schedule any sort of pause in scans or recordings. One can use MINPAUSE to keep the recording going through short gaps. For longer gaps when using MINPAUSE, the recording start time will not be affected. PRESTART (or a negative value for the old parameter PRESCAN) can be used to shift the scan start time forward from the time set by other criteria (such as antennas on-source when using DWELL). The start time is moved by the same amount for all stations and is not moved past the stop time of the most recent scan at any station.

For PCFS (VEX) controlled stations, the user should bear in mind that all start times currently (Oct. 2001) must be equal. SCHED will issue a warning if this condition is violated and will try to synchronize recording starts when using MINPAUSE.

In the tape era, it was possible for MINPAUSE to confound your attempts to leave gaps required by VEX files for tape reversals. In such cases, you would need to adjust MINPAUSE on the offending scans. The default should not cause this problem because it does not request continuous tape motion through scans long enough to keep the VEX check routines happy for a reversal.

Note that MINPAUSE used to be multiplied by the speedup factor to determine the actual length of a pause at record time. That made it actually a time of the pause at playback time on the old VLBA correlator. That concept is no long relevant so the multiplication by the speedup factor has been removed.

Argument: A number giving the minimum recording stoppage in seconds.

Options: Any number.

Default: 10 seconds for legacy systems and anything controlled by the Field System. It is 0 for anything else including the VLBA/RDBE and VLA/WIDAR systems.

Usage: Defaults to previous scan.

Example: MINPAUSE=30

MONTH

MONTH is the month of the stop time of the scan. The day of year of the first day of the MONTH, minus 1, is added to the value for SCHED parameter DAY to get the day of year of the project. Thus MONTH can be specified and DAY given as the day of the month, or MONTH can be left at the default of 1 and DAY can be given as the Day of Year (DOY). Other combinations are also possible, but don’t make much sense.

Argument: Integer.

Options: Any between 1 and 12.

Default: 1

Usage: Defaults to previous scan.

Example: MONTH=10, meaning October.

NCHAN

NCHAN is an obsolete parameter used in conjunction with FREQ and BW. Now that setup files are required, the number of channels is obtained from them.

NOSETUP

NOSETUP tells SCHED to ignore all setup file handling. This is meant to aid in planning when trying random or hypothetical stations so that a setup file or frequency file entry for such stations is not needed. If this is specified, no telescope control files can be written. However, the plotting section is functional.

If NOSETUP is specified, do not give SUMITEM=TAPE1 or TAPE2.

Argument: None.

Options: Any none zero argument is the same as not specifying it.

Default: Not specified.

Usage: Only one value used per experiment.

Example: nosetup

NOTE1, NOTE2, NOTE3, and NOTE4

NOTE1, NOTE2, NOTE3, and NOTE4 are 128-character text strings that can be used to pass any information in the cover section. Instructions regarding pointing, Tsys measurement, and where to send logs are typically provided this way. Do not use exclamation marks (“!”). They mess up the VLBA system’s ability to parse the control files. SCHED will die if you try.

Argument: Each of the 4 parameters takes a character string of up to 128 characters.

Options: Any text.

Default: Blank

Usage: Uses only one value, the last.

Example: NOTE1=’Please measure Tsys for every scan.’

OBSMODE

OBSMODE gives basic information on the technical nature of the project. The receiver wavelength and the recording system to be used should be noted. Any non-standard setup should be noted here, and expanded on with NOTE1, etc. This is for the cover information.

Argument: Text of up to 58 characters.

Options: Any - include receiver wavelength and recording system.

Default: Blank

Usage: Only one value used, the last.

Example: OBSMODE=’6cm Mark II Standard Network setup’

OBSPHONE

OBSPHONE is the phone number for Principal Investigator during the observations for the cover information.

Argument: Text of up to 49 characters.

Options: Any - usually a telephone number.

Default: Blank

Usage: Only one value used, the last.

Example: OBSPHONE=’+1-505-835-7392’

OBSTYPE

OBSTYPE tells SCHED what type of observation this project is. There are really only four options, although there are several ways to specify most of them. They are:

Mark II.
Specifying either OBSTYPE = MKII or MARKII causes SCHED to assume that the Mark II recording system will be used. This system is now obsolete, although maybe not totally gone, so this should not be common. It causes tape change requests to occur at time intervals specified by AUTOTAPE and assumes the Mark II tape is to be left running.
Wide band recordings.
Specifying VLBI, VLBA, MKIII or MKIV causes SCHED to assume that the wide band recorders (tape or disk) are in use. For the wide band recording modes, the necessary information on tape speed, passes per index position, etc., is taken from the setup file and the TAPEFILE and the type of recorder to use is based on the station catalog and the TAPEFILE parameter MEDIA. If there is a gap between the stop time of one scan and the start time of tape motion in the next (after taking into account START, DWELL, GAP, and PRESCAN), then SCHED will insert a dummy scan with no tape motion (or possibly a rewind or fast-forward) during this gap. Note that there is no requirement that the FORMAT in the setup file match which OBSTYP is specified. In fact, it is allowed to mix types at different stations. For historical reasons, VLBA, MKIII, MKIV, MARKIII and MARKIV are allowed alternatives with the same effect as VLBI and some of these appear in the examples.

SCHED does not support Mark III recordings on other than VLBA systems — the snap output contains no tape commands. In any case, Mark III is obsolete and no longer in use.

Pure VLA observations.
If OBSTYPE = VLA, SCHED will assume that only the VLA is being scheduled and that VLBI recorder setup or commands are required. This is the mode in which SCHED can be used for many types of VLA scheduling. With the advent of the EVLA project, SCHED should no longer be used for scheduling pure VLA projects so this option is basically obsolete.
Single dish observing.
OBSTYPE = NONE or PTVLBA (the default) causes recorder handling to be ignored. This is mainly for VLBA single dish pointing observations. This does set up the channels in the Data Aquisition System (BBCs, IF distributers etc), but does not record VLBI data.
Configuration studies.
OBSTYPE = CONFIG causes a map of station locations to be plotted when plotting uv coverage for multiple sources. This is mainly for array design configuration studies. The axis limits are set with parameter MAPLIM and default to values appropriate for NMA configuration studies. Continental, national, US state, and New Mexico roads will also be plotted if the vector files are available in $PLANET_DATA as they are in Socorro. If you want to use this capability, you might wish to contact Craig Walker about details and help — it is not really meant for general use.

Argument: Text of up to 8 characters, not case sensitive.

Options: MKII, MARKII, VLBI, VLBA, MKIII, MARKIII, MKIV, MARKIV, VLA, PTVLBA, CONFIG, or NONE.

Default: NONE

Usage: Only one value used per project.

Example: OBSTYPE=MKIII

OPDUR

OPDUR is the total duration of project being scheduled with an optimizing mode. Some of the optimizing modes keep generating new scans until they run out of time scheduled for the project. This parameters informs SCHED of the total project duration.

Note that the optimizing modes are somewhat experimental. If they are used, the output schedule should be checked carefully.

Argument: A time in time format (eg hh:mm:ss)

Options: Any time that is to be used as the length of the project.

Default: 0

Usage: Only one value used per project

Example: OPDUR = 13:30:00

OPELPRIO

OPELPRIO is used to specify two elevation ranges (4 values) to give high priority when optimizing a schedule. With OPTMODE=SCANS, scans on a source that falls within these elevation ranges will be taken every time while scans falling outside these ranges at all stations may be skipped depending on the setting of OPSKIP and on what happened on previous opportunities to observe the source. For geodesy projects, for example, priority might be given to very low elevations (for atmospheric determination) and very high elevations (to get good leverage on the parameter fits).

Note that the optimizing modes are somewhat experimental. If they are used, the output schedule should be checked carefully.

Argument: Four real numbers to be interpreted as elevations in degrees.

Options: Any valid elevation (0 to 90 degrees)

Default: All zero.

Usage: Only one set of values, the last, used for the project.

Example: OPELPRIO = 2., 15., 75., 90.

OPHA

OPHA is the parameter for OPTMODE=HAS that sets the desired hour angle at the reference station OPHASTA for this scan. If this parameter is not set, SCHED figures out how many scans there are on the source, when the source can first be seen (either because of elevation limits or experiment start time) and when it can last be seen. It then spaces the desired observation times evenly between those times.

The weight based on deviation from the desired hour angle is calculated using the formula:

  TIMEWT=OPHAWT(JSCN)*(0.5+(1.0/PI)*  
           ATAN(1.5*(TAPPROX-OPHAT(JSCN))/ OPHAWIDT(JSCN)))

where OPHAT is OPHA converted to a time, TAPPROX is the proposed observe time of the next scan, and OPHAWT and OPHAWIDT are other SCHED input parameters. Note TAPPROX is likely to be adjusted slightly once the scan is chosen and full account of slew times is taken.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

OPHMAXDT

OPHMAXDT is the parameter for OPTMODE=HAS that sets the maximum deviation from the desired hour angle that a scan will be considered. This helps limit the number of scans considered at any one time but, most importantly, prevents use of the scan at an inappropriate time, for example, because no appropriate scan was available at that time. Because of this parameter and OPDUR is is possible to not use all input scans. Users should watch for this and probably adjust scan parameters to fix the problem.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real time

Options: Any

Default: 2:0:0 (2 hours)

Usage: Uses the most recent value specified.

Example: OPHMAXDT = 30:00

Argument: Any real hour angle

Options: Any

Default: Zero. SCHED will pick the values. The default is usually what you will want.

Usage: Uses the last value specified. It is not a good idea to specify one and not the others as then all scans will have the same desired hour angle and the behavior will probably be a bit weird.

Example: OPHA=PT

OPHAWID

OPHAWID is the parameter for OPTMODE=HAS that sets the normalization time (normal time format) for the tolerance for deviation from the specified hour angle. A larger value allows SCHED to be a more sloppy with placement of the scan.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real time, usually in a format like 30:00 for 30 minutes.

Options: Any positive value

Default: Zero. Set to the spacing between desired scans on the source.

Usage: Uses the most recent value specified.

Example: OPHAWID = 30:00 (for 30 minutes)

OPHAWT

OPHAWT is the parameter for OPTMODE=HAS that sets the relative importance of the deviation from the desired hour angle compared to minimizing slew time or getting a scan near a limit.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real number. But negatives don’t really make sense.

Options: Any

Default: 1.0.

Usage: Uses the most recent value specified.

Example: OPHAWT = 3.5

OPHASTA

OPHASTA is the parameter for OPTMODE=HAS that sets the reference station at which hour angles are calculated. It is usually best to choose a station in the middle of the array, such as Pie Town (VLBA_PT or PT) for the VLBA.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: A station name or station code matching a scheduled station.

Options: Any valid station in the schedule

Default: PT

Usage: Uses the one value for the experiment - the last specified.

Example: OPHASTA = VLBA_LA

OPHLIMTI

OPHLIMTI is the parameter for OPTMODE=HAS that sets the normalization for the time offset from the limits of when a source is up. The equations for the weights for rise and set are:

  RISEWT=MAX(0.0,OPHLIMWT(JSCN)*(1.0-ABS(HA1(JSCN,RSTA)-HAMIN(JSCN))*  
             3600.0/OPHLIMTI(JSCN)))  
  SETWT=MAX(0.0,OPHLIMWT(JSCN)*(1.0-ABS(HA1(JSCN,RSTA)-HAMAX(JSCN))*  
             3600.0/OPHLIMTI(JSCN)))

where HA1 is the hour angle of the proposed scan, HAMIN and HAMAX are the hour angles at which the source rises or sets. This only worries about the rise and set times. Some day it maybe should also worry about experiment start and end.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real hour angle - in seconds.

Options: Any

Default: 1800.0

Usage: Uses the most recent value specified.

Example: OPHLIMTI = 1200.D0

OPHLIMWT

OPHLIMWT is the parameter for OPTMODE=HAS that sets the relative importance of the weighting based on being near the rise or set time of a source. For the equations for these weights, see OPHLIMTI.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real number

Options: Any

Default: Zero.

Usage: Uses the most recent value specified.

Example: OPHLIMWT = 1.0

OPMINSEP

OPMINSEP is the parameter for OPTMODE=HAS that is used to prevent two scans on the same source from being scheduled too close together. SCHED determines the default spacing of scans — evenly spaced across the available time — regardless of whether the user overrides that default by specifying the desired hour angles. That default spacing is multiplied by OPMINSEP to get the minimum separation. Once a scan is scheduled, another scan on that source will not be scheduled until after that minimum separation has passed. A different value can be given for each scan.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real hour angle, although usually a fraction between about 0.0 and 1.0

Options: Any

Default: 0.0 which means don’t have a minimum separation.

Usage: Uses the most recent value specified.

Example: OPMINSEP = 0.4

OPMISS

OPMISS is used to reduce the priority of some sources when using OPTMODE = ’SCANS’. The current scan will only be accepted if the OPMISS scans have been skipped. See OPTMODE for more details.

Argument: Any integer

Options: Any

Default: Zero. No scans will be skipped.

Usage: Uses the last value specified. So if one scan is given a high number, be sure to drop the value for the next.

Example: OPMISS = 7

OPMINEL

OPMINEL specifies the minimum elevation in degrees below which sources will be considered to be “down”. In all modes, if less than OPMINANT antennas are up, the scan will be skipped.

This is used mainly for optimizing modes to help select scans, and for experiment planning in order to, for example, plot the uv coverage available if all low elevation data and all data with less than several antennas will be discarded. The default will have no effect on schedules.

Argument: A real number to be interpreted as an elevation.

Options: Any valid elevation.

Default: 0.0

Usage: On per scan. Defaults to previous scan.

Example: OPMINEL = 15.

OPMINANT

OPMINANT sets minimum number of antennas for which the source must be up for the scan to be accepted. To be up, a source must be above the telescope slew limits, any specified horizon, and above OPMINEL.

This is used mainly for optimizing modes to help select scans, and for experiment planning in order to, for example, plot the uv coverage available if all low elevation data and all data with less than several antennas will be discarded. The default will have no effect on schedules. A separate value can be specified for each scan.

Argument: An integer.

Options: Any

Default: 0

Usage: One per scan. Defaults to previous scan.

Example: OPMINANT = 4

OPNOSUB

OPNOSUB tells the SCHED optimizing modes not to allow subarraying. All antennas are to be scheduled in all scans, regardless of whether the source is up.

Note that the optimizing modes are somewhat experimental. If they are used, the output schedule should be checked carefully.

Argument: None

Options: None

Default: Not set — allow subarraying.

Usage: Only one value used for schedule — the last.

Example: OPNOSUB

OPPRTLEV

OPPRTLEV tells the SCHED optimizing modes how much extra information on the inner workings of the scan choice to print. So far, it is only used for OPTMODE=HAS. See the description in the section on OPTMODE for details.

Argument: A integer.

Options: Useful values are between 0 and 3

Default: 0, which gives only bare summaries.

Usage: Only one value used for schedule — the last.

Example: OPPRTLEV=3

OPSKIP

In optimizing mode “SCANS”, skip each source OPSKIP times after it is last seen, unless it is in the OPELPRIO elevation range. This parameter is not applied to pointing (and Ta and PN3DB) observations when they are mixed with other types of scheduling. It is always applied when OBSTYPE is NONE or PTVLBA.

Note that the optimizing modes are somewhat experimental, especially this one! If they are used, the output schedule should be checked carefully.

Argument: An integer, usually small.

Options: Any

Default: 0

Usage: Only one value used for schedule — the last.

Example: OPSKIP = 2

OPSLEWTI

OPSLEWTI is the parameter for OPTMODE=HAS that is used to normalize the weighting based on slew time. The slew time weight is set by the equation:

 SLEWWT = MAX(0.0,OPSLEWWT(JSCN)*(1.0-OPSLEW/OPSLEWTI(JSCN)))

Where OPSLEW is the difference between the stop time of the previous scan and the time when all antennas are ready to observe the scan being tested.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real hour angle

Options: Any

Default: Zero.

Usage: Uses the most recent value specified.

Example: OPSLEWTI = 1:0:0

OPSLEWWT

OPSLEWWT is the parameter for OPTMODE=HAS that sets the relative importance of the weight based on slew time compared to the other weights. See OPSLEWWT for the equation used to set the slew weight for a scan.

See the discussion of the possible optimization modes in the section on OPTMODE for more information on OPTMODE=HAS

Argument: Any real number. Positive is best.

Options: Any

Default: Zero. Don’t pay attention to slew times.

Usage: Uses the most recent value specified.

Example: OPSLEWWT = 1.0

OPTMODE

OPTMODE sets the optimization mode. The valid modes are:

NONE.
This is the default. The input schedule will be used as specified.
SCANS.
For this mode, the schedule will be followed as specified. However only scans with more than OPMINANT antennas with the source up (above the horizon and within the slew limits) and above OPMINEL will be accepted. For each accepted scan only those antennas that are up and above OPMINEL will be scheduled unless OPNOSUB is specified. DWELL would normally be specified to allow for slews. Subarraying will happen if two successive sources can only be seen by different antennas since the optimization keeps track of the previous scan on a per-antenna basis.

The usual way to use this mode is to specify a loop containing all the desired sources (and frequencies etc.) and lasting longer than the desired total time. Then the optimization will pick the scans that make sense and will quit after OPDUR. This mode is especially useful for scheduling pointing observations.

There is a trick available, triggered by OPSKIP, that is an attempt to emphasize scans in desirable elevation ranges (set by OPELPRIO. If a loop is used, this will cause scans to be skipped OPSKIP times before they are used again unless they are in the desired elevation ranges.

There is another trick to give low priority to some scans using OPMISS. The current scan will only be accepted if at least OPMISS preceding scans in a row have been missed. If, for example, you have a loop of scans, as is typical in pointing schedules, and you have one that you only want to have used if all others are unacceptable (eg too low), then set OPMISS to the length of the loop.

CELLS.
For this mode, the input scan list is treated as a pool of possible scans. The sky over each antenna is divided into 9 cells (3 X 3 in Az and El) and the time that each cell was sampled is recorded. For each output scan, all input scans are checked for which cells they sample and a weight is calculated based on the time since the last time that cell was sampled. The weight is adjusted to discourage long slews with the characteristic time scale of that discouragement set by OPTSLEW in minutes. Also, if some low elevation cells for a station have not been sampled in a long time (characteristic time scale set by OPTLOWT, the weight for other low elevation cells will be increased. This tries to compensate for edge stations that have no mutual visibility with the rest of the array for sources at low elevation in certain directions. The input scan to use is then selected based on the adjusted weights.

This mode is an attempt to provide a mechanism for scheduling geodetic type observations. Parameters OPMINANT, OPMINEL, OPDUR, and OPNOSUB have the same meanings for CELLS mode as for SCANS. The CSUB mode is able to do almost the same thing as this mode plus it handles subarraying. It may eventually completely replace the CELLS mode.

CSUB.
This mode is much like the CELLS mode except that it uses subarrays. The sky over each antenna is divided into 9 cells. For each possible pair or sources, a scan is constructed with each antenna observing the source for which the priority is highest. The priority is the result of the time since the cell the source is in was sampled adjusted to downweight long slews (OPTSLEW) and upweight low elevation scans when other low elevation cells are not being sampled (OPTLOWT). If the minimum number of antennas per scan ( OPMINANT) is not satisfied, some are shifted so that it is. Then the subarrayed scan is compared with single source scans with each of the two sources and the best option chosen. There is a weighting factor which favors the single source cases and has been adjusted so that something less than half the scans include all stations. Some day this should be made an input parameter. Finally, if there are more than 2 antennas left over, they are put in a third subarray with an optimized source.

Like the CELLS mode, this mode is for geodetic type observations. Various parameters have the same meaning here as for the other modes except that OPNOSUB is not allowed since it doesn’t make sense. Also, OPMINANT is a goal. The third subarray can have less as can one of the other two under certain very special circumstances.

UPTIME.
This mode is designed for experiment planning. For each input scan, it creates a string of scans of duration DUR or DWELL, spaced by GAP (helps interpret UV plots), and lasting for total time OPDUR. All such series of scans start at the start time of the first scan. Usually (OPDUR=24:00:00) would be used to examine a whole day or the actual start time and total duration of allocated time would be used. Each input scan would normally be on a different source. Note that this mode gives a backward time jump at the first scan based on each input scan. For this reason, writing telescope control files based on this optimization mode is not allowed.
HAS.
For this mode, the user provides the scans that should be observed. All parameters of the scans are retained, except the times. As SCHED runs, once one scan is processed, the next is chosen from those that remain based on an attempt to come close to the desired reference station hour angle. The user can specify the desired hour angle, or can take the default which is to spread the scans on each source evenly over the time interval during which it can be observed with enough stations above a specified elevation limit. The scan is chosen based on a weight which is the sum of a weight based on deviation from the desired time, a weight based on the slew time from the previous scan (to help try to minimize time lost to slewing), and weights based on proximity to the start and end of the time the source can be observed. There is an example schedule among the sched examples called eghas.key that shows a way of using this mode for survey type observations where there is a desire to observe many sources, each over a wide hour angle range to get good UV coverage.

OPTMODE=HAS should not be used to schedule projects longer than 24 hours. In that case, hour angles can be ambiguous. Note that for normal schedules the 4 minute difference between the sidereal and solar days will not be important partly because only scan start times are considered. However there is just a chance of weird behavior for an observation of 24 hours UT duration and short scans.

There are a number of input parameters to help guide the HAS mode in it’s selection of scans. Important parameter include OPDUR, which sets the total length of the observations, OPMINANT, which sets the minimum number of stations that must be up for a scan to be chosen and OPMINEL, which sets the minimum elevation a station must be above to be considered to be up. Note that to be considered to be up, a station must also be above the local horizon as specified in the station catalog.

OPHASTA sets the reference station for this mode. This is the station at which the hour angles will be measured. Either the full name or the station code, if unique, can be used. OPHA sets the desired hour angle (at the reference station) for this scan. OPHAWID sets a normalization time interval relative to the desired hour angle over which the scan weight increases. OPHAWT is a normalization factor for weights related to time offset from the desired hour angle. This and other weight normalization factors mentioned below help adjust the relative importance of the different factors such as offset from the desired time, slew time, and proximity to other scans on the same source. OPHASTA is used to set the station for which the desired hour angles apply. OPMINSEP sets the minimum separation of scans on a source as a fraction of the spacing of scans that would be used if they were spread evenly across the available time for that source. OPSLEWTI and OPSLEWWT set the reference time and the normalization factor for the weights related to slew time. The slew weight is OPSLEWWT * ( 1 - (slew time))/OPSLEWTI). OPHLIMTI and OPHLIMWT set a similar normalization and weight for the proximity to the extreme times at which a source can be observed. This latter is used to encourage a scan on the source, for example, before it sets. OPHMAXDT sets the maximum deviation from the desired hour angle at which a scan will be considered. This prevents using very inappropriate scans when no other scans are available. Most of the above parameter can have different values for different scans.

The equations for the various weights are given in the descriptions for the parameters OPHA, OPSLEWTI, and OPHLIMTI. For the most accurate information on how weights are set, look at the code in $SCHED/src/Sched/opthas.f.

When the HAS mode is used, a lot of information from the guts of the algorithm can appear in the sched.runlog depending on the setting of the parameter OPPRTLEV. For each output scan, some details of the weights etc for each possible choice from among the input scans are given (OPPRTLEV=3) or just a summary for the scan can be given (OPPRTLEV=2 or higher). At the end, for OPPRTLEV=1 or higher, the properties (like available observing time) and fate of each input scan are given in a table. Also a number of summary parameters are given for any OPPRTLEV. All this information, while bulky, should help a user figure out how to drive the program — how to set set the related input parameters. But beware that, for OPPRTLEV=3, the sched.runlog can be very large.

While constructing a schedule using this mode, it is very useful to use the plotting capability of SCHED. The UPTIME and UV Plot capabilities are especially useful in understanding what you have. Also note that when SCHED runs, it creates an output file with the extension .sch that could be used as the scan input section for another run of SCHED. So if the optimization mode comes close, but you wish to make a small change, it is possible. This is an old but little used capability and has not actually received any maintenance for a long time as of late 2005.

In its early form, the HAS mode is meant to be useful particularly for scheduling surveys. But at the moment, there is no way to associate scans so it would be difficult to use it for phase referencing. Also it would be awkward to use to schedule blocks of scans around the sky for atmospheric solutions (for aips task DELZN). These limitations should be removed in future versions.

HIGHEL:.
This mode is used, mainly for test observations, to allow SCHED to pick a scan with good elevation across the array from among a group of scans. The number of scans from which to pick is specified with HIGROUP. SCHED will do the geometry calculations for each of the HIGROUP scans and pick the one with the highest minimum elevation. It will keep that scan and skip the others in the group. This is especially useful for the data quality tests and startup scripts. See example dqhiel.key.

In some optimizing modes, SCHED will not schedule a scan that crosses 0 hr UT. This is also used to be true for dwell time scheduling, but it no longer seems to be useful — downstream processing doesn’t trip over such scans.

Note that the optimization modes are somewhat experimental. If they are used, the output schedule should be checked carefully.

Argument: A mode.

Options: ’NONE’, ’SCANS’, ’CELLS’, ’CSUB’, and ’UPTIME’

Default: NONE

Usage: Only one used in schedule --- the last.

Example: OPTMODE ’CELLS’

OPTLOWT

OPTLOWT is a time scale in minutes for upweighting any low elevation data in optimization modes CELLS and CSUB if other low elevation cells are not being sampled. See OPTMODE for more details.

Argument: Any time in minutes (mmm.mm format)

Options: Any time

Default: 15 — this is a reasonable value.

Usage: Only one value used for project.

Example: OPTLOWT = 10

OPTSLEW

OPTSLEW is a characteristic time scale in minutes for slews beyond which to start discouraging use of scans on the grounds that the slews are too long. This is used for several optimizing modes. See the description of OPTMODE for more details.

Argument: Any time in minutes (mmm.mm format)

Options: Any time

Default: 1.0 — a reasonable value.

Usage: Only one value used for project

Example: OPTSLEW=2.0

OVERRIDE

OVERRIDE is a switch that programmers can use to allow them to bypass restrictions imposed on most users. Commonly this will be to allow them to test features that users are not yet allowed to try. It is unlikely to be useful to users, only to programmers.

OVERwrit

If OVERwrit is specified, SCHED will overwrite any output files that already exist on disk. By default, SCHED will abort if it finds any old files of the same names as those it is trying to create. That mode is provides some protection against errors, but may be annoying when running lots of test cases.

Argument: None

Options: None

Default: Do not overwrite files.

Usage: Only one specification used — the last

Example: OVERWRIT

PCAL

PCAL sets the mode of the pulse cal generators on the VLBA. The generators can be off or can generate tones every 1 MHz or every 5 MHz. The input here can be used to change the mode from scan to scan. A default can be established in the setup file. Note that, if PCAL is specified in the schedule, it will override what is in the setup file, even if a new setup is invoked.

Control over the phase cal detection is not implemented for telescopes controlled by means of the VEX file. See notes on MkIV and S2 for details. In the EVN, standard practice is to use 1 MHz spaced tones at integer MHz values. Spectral line users that want to switch phase-cal insertion off should send special instructions to individual telescopes, as well as specifying it correctly in the schedule.

Argument: The pulse cal mode.

Options: , ’off’, ’1MHz’, or ’5MHz’. A causes the setup file value to be used.

Default: Use the setup file value. If none there, use ’1MHz’.

Usage: Defaults to previous scan. This applies even if there is a change of setup.

Example: PCAL=’off’

PCENTERS

Specifying PCENTERS followed by a ”/” causes SCHED to read groups of phase centers for use with multiple-phase center processing on the DiFX correlator. This is much like the reading of in-line catalogs with SRCCAT or STACAT. Each specified group has a name specified with NAME and a list of source names specified with SOURCES. All of these sources should be in the source catalogs. It will be common to use a file, specified with SRCFILE2 to specify all the “sources” used as phase centers.

After the last phase center group, a line with ENDCENT / should be given to return SCHED to reading normal program input. There is an example egcent.key that demonstrates the capability. The main effect will be the listing of the phase centers

Argument: Just the word PCENTERS followed by a ”/”

Options: None

Default: Not used

Usage: Use only once per schedule file.

Example: PCENTERS /

PEAK and NOPEAK

PEAK, if specified, will cause commands to be issued to tell some antennas to peak up their pointing. NOPEAK causes SCHED to stop issuing those commands.

As of March 1999, PEAK is no longer used to control VLA pointing. Please see parameter VLAPEAK.

Warning, NOPEAK takes precedence over PEAK if given in the same scan. SCHED has no way to tell that the PEAK is new rather than left over from the previous scan. Often NOPEAK is given right after the peaking scan inputs to ensure that peaking doesn’t get left on in the next scan. But if that next scan is meant to be a peaking scan, say on a different set of antennas, you will not get what you want. We have received user files like this.

For the VLBA, if PEAK is greater than 0, a peakup will be done using the channel number specified by the PEAK argument. The peakup begins either when the scan starts, or when the antenna reaches the source, whichever is later. But the on-line system will wait for a maximum of 30 or 40 seconds to reach source before giving up. If it will take longer than that to reach source, a dummy scan or a gap between scans should be inserted. The peakup routine reads the total power after being on each position for 2 seconds and then goes on to the next position. The pattern contains 10 points. Therefore the peakup will take 20 seconds plus slew times which may be as little as 30 seconds - call it 45 seconds to be conservative - at high frequencies. It could take significantly longer at low frequencies but there is no good reason to use reference pointing there. After the peakup is done, the results will be used until either another peakup is done or the project code changes. Hopefully, we’ll have some way to turn it off eventually.

It will be common to peak up at a different frequency from that being used for observing (eg peak at 7mm for 3mm observations). It will also be common to peak on a line source during a continuum observation. Therefore a different setup file will be needed for the peaking scans. It is reasonable to use the standard pointing setup files. They have names like pt7mm.set. They use FORMAT=NONE which causes the on-line system on the VLBA to not touch the formatter. Note that this is very likely to mean that any pulse cal data gathered during such scans are likely to be spurious.

For stations other than the VLA and VLBA, adding a PEAK specification to a scan will help trigger reference pointing observations. This is common for the GBT and Effelsberg.

See the section on reference pointing for much more information on easy ways to insert pointing scans.

This command triggers the addition of REFERENCE_POINTING INTENTS to the VEX file. When similar intents are added using VLAPEAK, they are prepended by VLA:. When they are added because of the use of PEAK, they will not have a station identifier. The scans before the first scan in which reference pointing is requested with PEAK will have "INTENT = REFERENCE_POINTING_OFF". All scans for which PEAK is greater than zero will have "INTENT = REFERENCE_POINTING_DETERMINE". After the first determination, any scans with PEAK less than or equal to 0 will have "INTENT = REFERENCE_POINTING_APPLY". The PEAK scheme needs to be enhanced if we are going to treat different stations differently.

Argument: A digit that for the VLBA is a baseband channel number.

Options: See discussion above.

Default: Don’t peak up.

Usage: Defaults to previous scan.

Example: PEAK=3

PEAKFILE

PEAKFILE is used to specify an external file containing parameters to control automatic insertion of reference pointing scans. The default is the file provided with the SCHED distribution. The same information can be put in the main SCHED input using PEAKINIT.

Argument: A file name of up to 80 characters

Options: Any file name

Default: $SCHED/catalogs/peak.cmd on unix systems.

Usage: Only the last value specified is used.

Example: peakfile=mypeak.cmd

PEAKINIT

PEAKINIT tells SCHED that the following lines, up to a ENDPEAK are input in the same format as the PEAKFILE and as described in the section on reference pointing.

Argument: No argument.

Options: None

Default: Not set

Usage: Generally only used once.

Example: PEAKINIT /

PHONE

PHONE is the Principal Investigator’s telephone number before and after the project. See OBSPHONE for the number during the project. It is for the cover information. It must be provided for observations that record data.

Argument: Text of up to 64 characters.

Options: Any.

Default: Blank.

Usage: Only one value used, the last.

Example: PHONE=’+1-505-835-7392. (Ask for ET).’

PINAME

PINAME is the name of the Principal Investigator. Actually, the person who should be used here should be the one who is organizing the project, not necessarily the one leading the proposal. With 64 characters, more than one person could be given. SCHED will abort if PINAME is not given for observations that record data. This is for the cover information.

Argument: Text of up to 64 characters.

Options: Any.

Default: Blank, causing SCHED to abort.

Usage: Only one value used, the last.

Example: PINAME=’E.T. Smith’

PKWATCH

PKWATCH is used with the automatic insertion of reference pointing scans. If specified, information will be sent to the standard output about how pointing sources are chosen. This may help the user understand why expected sources are not used or other problems of the sort. It produces lots of output so it is best to redirect the program output to a file when it is used. In unix, this is done by running SCHED with a line of the form:

sched < eg3mmc.key > ptg.out

Argument: No argument

Options: None

Default: Not set — no special output

Usage: Only last value used.

Example: PKWATCH

PLOT

PLOT is a switch that activates the plotting section of SCHED which is described more fully in Section 1.5. If plotting is desired, it is best to start SCHED interactively and specify PLOT and SCHEDULE=yourfile.key /. SCHED will then go get the schedule from yourfile.key (substitute your actual schedule file name) and then come back for interactive input to the plot section.

Argument: None.

Options: None.

Default: No plotting.

Usage: Only one used per schedule — the last.

Example: PLOT

POINT

POINT is used to tell SCHED to convert this scan to a reference pointing scan. If the argument is zero (which is the value it will get if POINT is specified without an argument), all stations that are in any group and have appropriate frequencies as specified in the PEAKFILE (see also PEAKINIT) will be used. If POINT has a value, only stations in that group from the PEAKFILE will be used. When POINT is specified for a scan, SCHED restricts the stations to those in the pointing group(s), switches to the pointing setup file, sets DOPPLER if the source velocity (first) is not zero, turns off recording, and sets other parameters needed to make a pointing scan. The parameters of the main scan are not affected. The object is to allow the user to explicitly set the times and source for pointing, but allow SCHED to take care of all the other messy details of converting the scan to a pointing scan.

POINT=-1 means don’t add a pointing scan even if you can. This is useful especially when AUTOPEAK) has been specified, but you are doing low frequency scans.

To turn AUTOPEAK) back on after using POINT=-1, set POINT to a value less than -1, say -2 or -999 (the value it has in the program if not set).

Argument: None or a number. None means zero. The number specifies a pointing group. -1 means don’t add pointing here.

Options: Any integer 0 or above, but should match a pointing group if not zero

Default: Not set (actually set to -999)

Usage: Set back to the unset state for each scan to avoid doing the whole schedule in pointing mode

Example: POINT=2

PN3DB and NOPN3DB

PN3DB tells SCHED to write a VLBA tracking test sequence in the VLBA control file for this scan. NOPN3DB tells SCHED to stop writing such sequences. This parameter should only be of interest to VLBA operations staff. The sequence, which is not a loop, starts with a scan of length PTSLEW to set levels at the half power point, then does a 15 second scan at the same place to fix those levels, then does one scan each of length PTDUR at off source and on peak positions, then tracks the source at the azimuth half power point. That is followed by an off source, on source, and half power in elevation tracking sequence. PTINCR in the setup file is used to set the distance to the half power point. The periods of tracking are the full scan duration minus all the level fixing, off, and on scan durations, divided by two. Scan durations of about an hour are appropriate.

Argument: None.

Options: None to set. NOPN3DB to go back to non-pointing modes.

Default: Not used.

Usage: Reverts to previous scan if not specified.

Example: PN3DB

PRECDATE

The user provides SCHED with source coordinates in one of the J2000, B1950, or DATE coordinate systems. SCHED then determines the source coordinates in the other systems. The J2000 and B1950 systems are not stationary with respect to each other. To do a proper conversion, it is necessary to specify for which date to do the conversion. This date is specified using PRECDATE. When SCHED converts from, for example, B1950 to J2000 coordinates, it uses the B1950 equations to precess to PRECDATE, and then the J2000 equations to precess from there to equinox 2000. If the wrong date, by many years, is used, the errors in the conversions will be a few tenths of an arc second. This is enough to harm phasing of the VLA at high frequencies and enough to be rather undesirable for positions used on the correlator.

The correct PRECDATE to use depends on various factors. If the target source coordinates are being provided in the J2000 system, as they really should be, then it doesn’t matter much. The correlator and the VLA will be given the J2000 positions so no conversion is involved. Some antennas will be given B1950 coordinates for pointing, but for single dishes, the few tenths of an arcsecond differences that can be caused by different PRECDATEs are not important.

The more important case is when the user has a B1950 coordinate for the target source and wants SCHED to take care of the conversion to J2000. Then the correct PRECDATE should be used. The correct date depends on how the B1950 coordinates were measured. If they were determined based on absolute measurements made on some date, that is the date that should be used. However, most target source positions will be based on measurements of offsets from some calibrator. Then the date that should be used depends on the nature of the calibrator positions. E.g, MERLIN uses a PRECDATE of 1950.0 as the default in the STARLINK COCO precession routine. On MERLIN, The calibrator positions presumably are all based on measured positions originally determined in J2000 (by VLBI etc), then converted to the B1950 coordinates that are required by the on-line system. Those conversions have all been done assuming an “observe” date of 1950.0. Thus, if you have B1950 source positions determined by offsets from a calibrator using MERLIN, PRECDATE=1950.0 should be used.

If anyone knows what other systems of general interest do, let Craig Walker know and a section can be added here.

The default PRECDATE in SCHED has changed a few times over the years. Prior to 5 Aug 1997, a date of 1985.0 was hardwired into the program. After that, the user parameter was introduced with a default of 1997.0. On 6 May 1998, the default in the development version of the code, and hence the next release (unknown date at this writing) was changed to 1979.9, the old VLA value (the EVLA does not use B1950 coordinates at all).

Argument: A fractional year.

Options: Any valid time. See the discussion above.

Default: 1979.9

Usage: Only one value is used.

Example: PRECDATE = 1950.0

PREEMPT

PREEMPT is used to allow, or not, scans to be preempted for other purposes. There are two cases. PREEMPT = EXTRA tells /schedb and VLBA operations to treat the scans as extras that can be used to help fill gaps between projects that often occur with dynamic scheduling. PREEMPT = NO tells operations not to use the Pie Town and Mauna Kea antennas at the time of the scan for daily USNO Earth Orientation Parameter (EOP) observations. PREEMPT = OK means that the time of the scan can be used for the EOP observations on PT and MK.

The PREEMPT = EXTRA option should only be used for a block of scans at the beginning of the project and another at the end of the project. These scans can, and normally will, extend outside the time assigned by the Time Allocation Committee. The scans that do not have PREEMPT = EXTRA are considered to be the “core” and should stay within the time allocation. If SCHED finds any “EXTRA” scans in the “core”, it will complain and stop. The EXTRA scans should be designed to enhance the goals of the project but should not be critical to it as they may well not get observed. Also, they should not be used to do what is effectively a different project.

Scans that have PREEMPT = EXTRA will not be written to the output files other than the summary file unless they are included in the range of scans specified with DOSCANS. The files affected are the .vex, .oms, crd.xx, sch.xx, and .flag files. These include all the antenna control files, so as far as the telescopes are concerned, these scans do not exist unless explicitly included in DOSCANS. Generally DOSCANS should only be used by VLBA schedulers.

Starting in October 2011, the VLBA has been used to provide daily Earth Orientation Parameter (EOP) observations for the U.S. Naval Observatory in return for financial support for VLBA operations. These observations are a geodetic style run of duration up to 1.5 hours using the Pie Town to Mauna Kea baseline. The observations were happening within about 4 hours of 18 hours UT. In early June 2013, they were shifted to within about 4 hours of 7 UT, during the night.

These observations cause some disruption to normally scheduled projects. The fixed and dynamic projects are scheduled in the normal manner. Then, if possible, the USNO observations are inserted in gaps between other projects. If that is not possible, the USNO observations preempt the normal project for the two stations involved. An effort to minimize the impact on the normal project is made. Parameter PREEMPT allows the PI to help with that minimization by specifying portions of the project that can be preempted and portions that should be protected. For example, the parameter can be used to protect key calibration observations.

PREEMPT can be specified for each scan and has three allowed arguments — ’EXTRA’, ’NO’ and ’OK’. The default, ’OK’, means that the scan be preempted and is a “core” scan. ’NO’ means that it should be protected from preemption for the EOP observations. ’EXTRA’ means that this is an extra scan at the beginning or end. ’EXTRA’ implies ’OK’ as far as preemption for EOP observations is concerned. The parameter need only be specified when it changes.

SCHED will examine the PREEMPT specifications and identify time periods of at least 1.7 hours when all scans allow preemption. Those times are listed in the .sum file and the new .preempt file. Shorter periods that include the start and/or end of the project are also listed as those would allow a partial overlap with the USNO observations.

If there is a period of more than 4 hours between the > 1.7 hour preemptable periods, SCHED will complain. If such periods are left in the schedule, the user requests for scan protection may be ignored when choosing when to insert the USNO observations. If the whole project is less than 4 hours long and is all protected, a warning will be issued, but preemption would probably only occur if the project is adjacent to a higher priority project that also cannot be preempted.

If PREEMPT is not specified for any scans, but the project uses automatic generation of geodetic segments, the geodetic segments will have PREEMPT default to ’NO’. This helps avoid problems for legacy schedules.

Argument: A character string of up to 5 characters.

Options: ’EXTRA’, ’OK’ or ’NO’. No other strings allowed.

Default: ’OK’, except see text about geodetic segments.

Usage: Defaults to previous scan.

Example: PREEMPT = ’NO’

PRESCAN

The topic of controlling scan timing is discussed in detail in the Scan Times section.

Please note: PRESCAN is retained mainly for backwards compatibility and should not normally be used. However it may be useful for a few situations with modern schedules. For example, if the user using DWELL wishes to push the scan further away from the preceding scan, then adding a positive PRESCAN, and lengthening the DWELL time by the same amount will do the job. That is an alternative to increasing TSETTLE in the station catalog, which the user may not normally want to touch.

Originally, PRESCAN was the mechanism for introducing gaps between scans. However that function is now better handled using the separate parameters GAP, PRESTART, and MINPAUSE.

PRESCAN specifies a time by which to offset the nominal start of a scan from what has been determined based on all other criteria. It is applied after all scan timing has been settled. It won’t back up (negative value) over the stop of a previous scan, but it would be capable of messing up scan timing set by other parameters. It should only be used with considerable care as it should not be considered a carefully maintained feature.

Note that PRESCAN is treated as a UT time regardless of whether or not LST scheduling is specified (it is added to the start time after the schedule times are converted to UT internally in SCHED).

If you are writing VEX files, please see the discussion of restrictions on tape stop time given in the section on parameter GAP.

Argument: A time.

Options: Any time.

Default: Zero for all systems except legacy VLBA and MKIV DAR, for which it is 5 seconds.

Usage: Defaults to previous scan.

Example: PRESCAN=20, meaning start the scan 20 seconds late.

PRESTART

The topic of controlling scan timing is discussed in detail in the Scan Times section.

PRESTART allows the recording to be started before good data is expected. It was used to give time for earlier correlators to synchronize playback. All correlators now in use are able to sync quickly so the need to adjust start times to allow for synchronization is basically gone. In practice, the the Mark5A units take few seconds to get going on record which is why the default is 5 seconds for the legacy systems. For VLBA/RDBE and VLA/WIDAR systems, the default is zero. The following discussion is kept to describe the function of PRESTART while the parameter is available.

PRESTART gives a time by which to start the recording at a site before the nominal start time as established by START, GAP, DWELL, PRESCAN etc. Like PRESCAN, if the requested PRESTART moves the start of motion to before the stop time of the previous scan, the recording will just be kept moving. But, unlike PRESCAN, this time shift is done on a per-station basis — if a station was not participating in the previous scan, it’s recording start will be shifted the full PRESTART time, even if that means starting while other stations are still recording the previous scan. Also unlike PRESCAN, the shift due to PRESTART is not reflected in the scan times reported in the summary or sch files.

The amount of time by which the recording start is shifted before the nominal start time can be displayed using the TPSTART option in the SUMITEM list.

See the section on scan times for more information on controlling scan times.

For PCFS (VEX) controlled stations, the user should bear in mind that all start times currently (Oct. 2001) must be equal. SCHED will issue a warning if this condition is violated.

Starting the recording early allows time for the correlator to synchronize the inputs from different stations before the start of good data. Anytime the recording stops, the correlator takes time to resync. On the old hardware VLBA correlator, that time is empirically about 8, 13, and 25 seconds for speedup factors 1, 2 and 4 respectively. Therefore it was best to keep recording through short gaps. On other correlators playing Mark5 media, sync is rapid — on the order 1 second or less at the JIVE and MarkIV correlators and the DiFX software correlator (current VLBA), so these concerns are not so great.

One exception when it may be a good idea to stop recording is when there will be a formatter reconfigure. These happen when the internal switching in the formatter, or the pcal detection setup, change (number of channels, BBC assignments, sidebands, pulse cal detector frequencies etc.). The media does not receive good data while this is happening and the correlator can have problems recovering sync afterward. At least a normal resync must happen and occasionally (maybe 10-20% of the time) the correlator will get in a bad state and take a long time, maybe over a minute, to resync. If the media are stopped during a reconfigure, a resync will be done normally.

Argument: A time.

Options: Any time.

Default: 5.0 for legacy systems, 0.0 for VLBA/RDBE and VLA/WIDAR systems.

Usage: Defaults to previous scan.

Example: PRESTART=15, meaning start the recording 15 seconds early.

PTDUR

PTDUR is the duration of each scan during a pointing loop for the VLBA. This parameter should not be of concern to anyone but VLBA operations staff.

Argument: A time in seconds.

Options: Any.

Default: 20

Usage: Only one value accepted, the last.

Example: PTDUR=15

PTSLEW

PTSLEW is the time allowed in a pointing sequence to get to source before beginning the raster. This parameter should only be of interest to VLBA operations staff. In actual use, if a scan start time is specified, the interval between that start time and the previous stop time is added to the PTSLEW to set the duration of the slewing scan. For most pointing observations, it is probably best to set PTSLEW to something small, perhaps the same as PTDUR, and use dwell time scheduling.

Argument: A time in seconds.

Options: Any

Default: 160, a sensible choice.

Usage: Defaults to previous scan.

Example: PTSLEW=180

PTVLBA and NOPTVLBA

PTVLBA tells SCHED to write a VLBA pointing sequence in the VLBA control file for this scan. NOPTVLBA tells SCHED to stop writing such sequences. This parameter should only be of interest to VLBA operations staff. Note that this is not a peak in the sense that the antenna does not go to the derived position after the pattern. It is used for measuring pointing offsets and pointing equations. Parameters PTSLEW and PTDUR set, respectively, the time allowed to get to source and the time spent at each position in the pointing pattern.

Argument: None.

Options: None to set. NOPTVLBA to go back to non-pointing modes.

Default: Not used.

Usage: Reverts to previous scan if not specified.

Example: PTVLBA

QUAL

QUAL specifies a qualifier that will be written along with the source name to the VLA and VLBA schedules. It is useful for distinguishing scans of different types on the same source.

QUAL is not passed to a VEX file.

Argument: An integer of up to 3 digits.

Options: Any integer of up to 3 digits including sign.

Default: 0 but 1 for first scan of frequency switching if something else not specified. Depends on scan for pointing.

Usage: Reverts to previous scan if not specified.

Example: QUAL=34

RECord and NORECord

RECord tells SCHED to record data for this scan. Recording can be turned off by specifying NORECORD. This can be convenient for, as an example, VLA phasing scans.

NORECORD will insert scans in the VEX file, which have recorder = 0. This will lead to the desired function in some cases, namely a complete scan, but without data being recorded.

Argument: None. Actually a non-zero argument would have the same effect as specifying NORECORD

Options: None.

Default: Make the recording.

Usage: Reverts to previous scan.

Example: RECORD

REPeat

REPeat = n causes the scan to be repeated n times. If GROUP is specified with a value of m, it causes m scans, starting with this one, to be repeated n times. DURATION or DWELL should be used if REPEAT is used. REPEAT and GROUP, together, provide a simple looping capability.

Argument: An integer.

Options: Any.

Default: 1

Usage: Reset to 1 on next scan.

Example: REP=5

REVERSE

REVERSE is an obsolete parameter now that tape is no longer being used.

REVERSE requests that the direction of motion of the wide-band Mark III or VLBA tape be reversed at the start of the scan. No rewinds or fast forwards will be done if this is requested. REVERSE is not needed normally. SCHED checks each scan to see if it will fit in the current direction. If not, the tape will be reversed before the next scan begins. If REVERSE is specified with no argument, the tape will be reversed at all stations. If one or more station names are given, the tapes will be reversed at only those stations. Station codes may be used instead of station names.

Argument: None or a list of stations.

Options: No argument or the name of any stations in the scan. Not case sensitive.

Default: No reverse.

Usage: Reverts to no reverse on next scan.

Example: REVERSE or REVERSE=VLBA_KP,VLBA_LA

REWIND

REWIND is an obsolete parameter now that tape is no longer being used.

REWIND requests that the wide-band Mark III or VLBA tape be rewound before the scan starts and during the prescan. If REWIND is specified with no argument, the tape will be rewound at all stations. If one or more station names are given, the tapes will be rewound at only those stations. Station codes may be used instead of station names.

Argument: None or a list of station names.

Options: No argument or the names of any stations in the scan.

Default: No rewind, unless there is insufficient room left during a backward pass to fit the next scan or a tape change is requested.

Usage: Reset to no rewind for next scan.

Example: REWIND or REWIND=’vlba_fd’

ROTATION

ROTATION is used in VLBA test observations to specify an increment to the subreflector rotation value used for the subreflector position. This is added to the nominal position known by the on-line system for the particular receiver.

Note that changing the rotation also changes the pointing offset in a frequency dependent manner.

Argument: A rotation angle in degrees.

Options: Any rotation angle

Default: 0.0

Usage: Default to previous scan.

Example: ROTATION = 10

ROTPAT

ROTPAT causes SCHED to expand pointing patterns to include a raster in focus and rotation. The position offsets in this raster are specified by FOCOFF and ROTOFF. ROTPAT is only expected to be used by VLBA testers.

ROTPAT have a value which is the number of positions in focus/rotation in the pattern. It can only be used for 13cm, 6cm, 4cm, 2cm, 1cm, 7mm, and 3mm. Note that the overall scan must be ptslew plus rotpat times ( 2 times ptdur plus N times 10 times ptdur ) long to fit a full pattern with N pointing loops at each focus/rotation position.

A typical set of offsets would be ROTOFF=-1.5, 0, 0, 0, 1.5 and FOCOFF=0, -1, 0, 1, 0 with FOCPAT=5.

Argument: A number of focus/rotation positions. Up to 20.

Options: Any number up to 20.

Default: 0 - Only do the central focus/rotation position.

Usage: Only one used for the experiment

Example: ROTPAT=5

ROTOFF

ROTOFF gives the offsets in subreflector rotation for a focus/rotation raster. See ROTPAT for details.

The values are offsets to be multiplied by the nominal offset for the band as understood by the program.

Argument: Up to 20 real numbers - the number of nominal recrements in rotation for each position of a focus/rotation raster.

Options: Any number. 1.0 or 1.5 typically.

Default: 0.0

Usage: Only one set used per experiment.

Example: ROTOFF=-1.5,0,0,0,1.5

SCANTAG

SCANTAG allows the user to specify a name for the scan. That name appears in the summary file under the scan number. Note that it resets after each scan. This is just to help users with bookkeeping when constructing complicated schedules with loops and other constructs that complicate knowing which output scan is which scan in the summary. The name is limited to 4 characters to fit in the desired column in the summary file.

Argument: Any character string of up to 4 characters.

Options: Any character string.

Default: Blank

Usage: Reset after each scan, although all instances of that scan in a loop will share the name.

Example: SCANTAG=’Cal2’

SCHedule

SCHedule allows SCHED to be started interactively to specify options that might vary from run to run (such as PLOT, DEBUG etc.) and still get most of it’s input from an external file. That external file is specified with SCHedule.

Under unix, environment variables may be used. For example, if SCHED is defined to mean /users/cwalker/sched, the base area under which all sched stuff is kept (substitute your local directory), then one can specify one of the example schedules with SCHEDULE = $SCHED/examples/manual_1.key. Use the setenv (c or t shell) or export (korn shell) to set environment variables.

Argument: A file name of up to 80 characters.

Options: Any valid file name.

Default: Use interactive input.

Usage: Only one used. It will apply to all following input.

Example: SCH=/users/cwalker/bw12.key

SETINIT

Setup file information can be specified in the main input file. If SETINIT is specified, the next groups (to ENDSET), are assumed to be setup file information. The setup name will be the argument to SETINIT. Multiple setup files can be specified this way. An argument must be specified or the setup information will not be read.

If SETINIT is found, the end of the input group (everything up to the “/”) is not considered the end of inputs for this file. The next inputs after the setup data are entered will continue to apply to the current file (usually the first).

Since SETUP can specify a file name, when there isn’t an embedded setup file, it must be case sensitive. As a result, the case of the argument of SETINIT much match SETUP.

Argument: A setup file name of up to 80 characters. Case sensitive.

Options: Any character string. Must not be blank.

Default: Will not assume that setup information will follow.

Usage: Will revert to assuming no setup information will follow.

Example: SETINIT=BW008.6CM.SET

SETUP

The argument to SETUP is a file name where setup information can be found. A setup file must be specified. See Section 3.6 for details of what should be in the setup files. A new setup file can be specified for each scan for mode switching. The SETUP file name may refer to an external file that can be read by SCHED or it may refer to a setup imbedded in the main SCHED input following a SETINIT command, whose argument is the setup file name.

Under unix, environment variables may be used. For example, if SCHED is defined to mean /users/cwalker/sched, the base area under which all sched stuff is kept (substitute your local directory), then one can specify the setup file with SETUP = $SCHED/setups/v6cm-128-4-2.set. Use the setenv (c or t shell) or export (korn shell) to set environment variables.

Since SETUP can be a file name and some operating systems (unix, Linux) are case sensitive, SETUP must be treated as case sensitive, including when referring to an embedded setup (from SETINIT).

Argument: A file name of up to 80 characters. Case sensitive.

Options: A valid file name.

Default: No setup file used.

Usage: Defaults to previous scan.

Example: SETUP=’/users/cwalker/sched/v6cm-128-4-2.set’

SOURCE

SOURCE is used to specify the source name. It is required for the first scan and whenever there is a change. The name must match, in a case-insensitive sense, one of the names of a source in the source catalogs (recall that 5 different names or aliases are allowed for each source).

SOURCE may be the name of a Solar System object. If so, if an EPHFILE: has been specified, and if the object is not in the source catalog, SCHED will determine the position and planetary motion of the object using a JPL ephemeris. This position is very good — certainly good enough for use for pointing which is the primary use envisioned (note that much work would be required on the correlator to correlate planetary observations). There is a similar capability for pointing at satellites using orbital elements in SATFILE or TLEFILE that are specified in the SATINIT section.

The Solar System objects that SCHED understands are Mercury, Venus, Moon, Mars, Jupiter, Saturn, Uranus, Neptune, Pluto, and Sun. Topocentric positions and rates will be provided for VLBA antennas if one of these is specified. Note that SCHED does not understand how to specify moving objects to antennas that don’t use the VLA or VLBA control file types. Specifically, solar system sources are not currently supported for VEX output files.

Argument: Text of up to 12 characters.

Options: Any source in the catalogs.

Default: None.

Usage: Defaults to previous scan.

Example: SOURCE=’3C120’

SRCCAT

SRCCAT is a flag to indicate that the following inputs are to be treated as an in-line source catalog. See Section 3.2 for details of source catalog contents. The catalog input is terminated by ENDCAT / to resume schedule input. It is best to specify SRCCAT / as a separate line not part of other SCHED keyin input. SCHED stores the source catalog information in internal arrays which have a maximum size that may depend on the computer but is 500 in the distributed version. All sources found in in-line catalogs are stored in these arrays because they may be read before all scheduled sources are known. In contrast, when an external source catalog is read, only scheduled sources are kept. See the examples in Section B.3 for illustrations of how in-line source catalogs are used.

If SRCCAT is found, the end of the input group (everything up to the “/”) is not considered the end of inputs for this file. The next inputs after the source data are entered will continue to apply to the current file (usually the first).

Argument: None.

Options: None.

Default: Not used.

Usage: There can be as many in-line catalogs as desired, consistent with the maximum number of allowed sources in the in-line catalogs.

Example: SRCCAT /

SRCFILE

SRCFILE is used to specify the name of the external source file. See Section 3.2 for the required formats. The default SRCFILE is $SCHED/catalogs/sources.gsfc, although $SCHED/catalogs/sources.petrov is a good alternative. Assuming the environment variable $SCHED is set (see below), this is the usual SCHED source file. If SRCFILE=’none’ is specified then no external catalog will be read. The file name is simply passed to the operating system so all the usual behavior you expect normally apply, such as the use of the current directory if a path is not given.

Under unix, environment variables may be used. For example, if SCHED is defined to mean /users/cwalker/sched, the base area under which all SCHED stuff is kept (substitute your local directory), then one can specify the source file with SRCFILE = $SCHED/catalogs/sources.petrov. Use the setenv (c or t shell) or export (korn shell) to set environment variables.

There is an option to use a second source catalog file using SRCFILE2. This could be useful if one wishes to get calibrator information from the SCHED standard catalog, but also have a catalog of program sources. It is also useful when using the ability to specify many phase centers per pointing center.

SCHED will use the data for a source from the first catalog it reads that includes that source. It reads the in-line catalog first, then SRCFILE and then SRCFILE2.

Argument: A file name of up to 80 characters.

Options: Any file name or none.

Default: ’$SCHED/catalogs/sources.gsfc’

Usage: Use only once.

Example: SRCFILE=/users/cwalker/sched/sources.dat

SRCFILE2

SRCFILE2 is a second source file, treated identically to SRCFILE. This allows one to supplement the main SCHED catalog with a local, but still not embedded, catalog. It is likely to be especially useful for observations wanting multiple phase centers in each pointing center.

SCHED will use the data for a source from the first catalog it reads that includes that source. It reads the in-line catalog first, then SRCFILE and then SRCFILE2.

Argument: A file name of up to 80 characters.

Options: Any file name or none.

Default: Not used

Usage: Use only once.

Example: SRCFILE2=’centers.dat’

STACAT

STACAT is a flag to indicate that the following entries are part of the stations catalog. See Section 3.3 for details of the format. In-line catalogs can occur more than once in the SCHED keyin file. The station catalog input is terminated with a separate entry containing ENDCAT /.

If STACAT is found, the end of the input group (everything up to the “/”) is not considered the end of inputs for this file. The next inputs after the station data are entered will continue to apply to the current file (usually the first).

Argument: None.

Options: None.

Default: Not used.

Usage: Can occur as often as desired.

Example: STACAT /

STAFILE

STAFILE is the name of the external stations file. See Section 3.3 for the required formats. If STAFILE is not specified, it defaults to $SCHED/catalogs/stations_RDBE.dat. If STAFILE=’none’ is specified then no external catalog will be read.

This must be specified among the first scan inputs since SCHED will read the station catalog while setting up the first scan. If STAFILE is not specified with the first scan’s inputs, SCHED will read the default catalog. This is done because, while reading the scans, SCHED needs to know some station information (like codes in case you choose to specify them for the STATIONS input).

Under unix, environment variables may be used. For example, if SCHED is defined to mean /users/cwalker/sched, the base area under which all sched stuff is kept (substitute your local directory), then one can specify the station file with STAFILE = $SCHED/catalogs/stations_RDBE.dat. Use the setenv (c or t shell) or export (korn shell) to set environment variables.

Argument: A file name of up to 80 characters.

Options: Any valid file name or none.

Default: $SCHED/catalogs/stations_RDBE.dat

Usage: Only specify once.

Example: STAFILE=’/users/cwalker/sched/stations.dat’

START

The topic of controlling scan timing is discussed in detail in the Scan Times section.

START is used to specify the start time of the scan in UT. If LST was specified, START is assumed to be in local sidereal time. START must be specified for the first scan. For later scans, it will default to the stop time of the previous scan if not specified. Note that the start time will be adjusted by PRESCAN to the time that the recording starts.

Argument: A time in hh:mm:ss format.

Options: Any time.

Default: No default - SCHED will stop if first START is not given.

Usage: Defaults to stop time of previous time.

Example: START=13:15:00

STATions

STATions is used to specify the list of stations to be included in this scan. If there is any change to the list, the whole list must be given again. The station names given must match ones available in the station catalogs. The scans for any specific station must be in time order. Note that STATN is no longer an acceptable alternative.

The maximum number of stations that SCHED will handle is set in a parameter statement in an include file and can be varied according to the capabilities of the computer in use. At the time this was written, it was 22, but that may change.

You may specify the station code for any or all stations instead of the name. Sched will determine the station name from the catalog information and use it for the rest of scheduling. This use of station codes is only offered for STATions, FASTFOR, REWIND, TAPE, and REVERSE. All other inputs requiring station names must use the names as given in the station catalog.

Argument: A list of station names of up to 8 characters each.

Options: Any stations in the station catalog.

Default: At least one must be given for first scan.

Usage: Defaults to previous scan.

Example: STATION=EB_VLBA,GB_VLBA,VLBA_NL,VLA27,VLBA_MK

STOP

The topic of controlling scan timing is discussed in detail in the Scan Times section.

STOP is used to specify the stop time of the scan in UT. If LST is specified, the time is in local sidereal time. Either a STOP time, a DURation, or a DWELL must be given for each scan, although the DURation or DWELL can default to a previous value. If STOP and one of the others are both given then the implied stop times are compared, and if those times differ by more than 10 seconds, a complaint is generated. A simple check of a long schedule made in durations is to include the stop time for the last scan; if the schedule has problems, there will be an error message.

Argument: A time in hh:mm:ss format.

Options: Any time.

Default: Start time plus duration.

Usage: Either DURation, DWELL, or STOP is required for each scan. DURation or DWELL will default to previous scan.

Example: STOP=13:45:00

SUMITEM

SUMITEM is used to control the items listed in the summary file for each antenna. Two items are listed for each scan for each antenna on each summary pass. Up to 10 items can be requested causing up to 5 summaries to be produced in the .sum file. The items that can be requested are:

EL1:
The elevation at the start of the scan. For scans where the source is below the hardware limits or the horizon, a letter code will be included.
EL2:
The elevation at the end of the scan. The limit code will be included.
ELA:
The average elevation of the scan ((EL1+EL2)/2). The limit code will be included.
AZ1:
The azimuth at the start of the scan. The limit code will be included.
AZ2:
The azimuth at the end of the scan. The limit code will be included.
AZA:
The average azimuth of the scan ((AZ1+AZ2)/2). The limit code will be included.
PA1:
The paralactic angle at the start of the scan.
PA2:
The paralactic angle at the end of the scan.
HA1:
The hour angle at the start of the scan.
HA2:
The hour angle at the end of the scan.
EARLY:
The number of seconds that the antenna arrived on source before the scan started. Negative numbers are common and are the number of seconds that the antenna arrived on source after the scan started.
DWELL:
The number of seconds of on-source time in the scan. This does not take into account correlator resync times. See SYNC for that information. The total integration time should be the smaller of DWELL and SYNC. Note that neither takes into account the time needed to switch between receiver bands (that’s on the wish list).
SLEW:
The slew time in seconds from the previous source.
TAPE1:
The tape drive in use, the recording direction, and the head index position. Cannot be used if NOSETUP is specified. If the station only has disk, the total GBytes recorded at the station up the the end of the scan is given.
TAPE2:
The set of heads in use (for example which of the TRACKn inputs is in use) and the tape footage in thousands. Cannot be used if NOSETUP is specified.
DISK:
The total GBytes recorded at the station up the the end of the scan is given. Nothing useful is given for tape only stations. Cannot be used if NOSETUP is specified.
TPSTART:
Show the offset of the recording start time from the scan start time. This is established by parameters PRESTART and MINPAUSE
SYNC:
The expected integration time with the correlator synchronized. This takes into account time lost to resyncs and formatter reconfigures. It does not take into account slew times, which DWELL does.

If any other items are desired, please inform Craig Walker.

Users of EVN antennas (and any others controlled by the PCFS and VEX) are advised to study the listing created by EARLY. Currently there is no complete mechanism for PCFS to monitor whether the telescope was on source when the recording starts. Data taken during this time are invalid, but are not flagged automatically. Therefore it is advisable to make schedules with DWELL or inspect the listing for telescopes that arrive late on source.

Argument: Up to 10 character strings.

Options: See the description above for valid parameters.

Default: ELA, DWELL

Usage: Only one value used, the last.

Example: sumitem=el1, az1

TANT1 and TANT2

TANT1 requests that SCHED turn on antenna temperature measurement at stations in the TANTSTA1 list, if it knows how to do so for those antennas. TANT2 does the same thing for stations in the TANTSTA2 list.

This command currently has no effect on VEX, VLA, or VLBA output. In fact, as more antennas have gone to the above file types, the usefulness of this capability had been significantly reduced. As of mid 1997, the only station for which automatic Tant requests can be made is Green Bank. Be warned that such measurements take a minute or so.

Argument: None or a non-zero value.

Options: None or 0 to turn on Ta measurements. Specify a non-zero value to turn off Ta measurements.

Default: Make the Ta measurements.

Usage: Defaults to previous scan.

Example: TANT1=-1 TANT2

TANTSTA1 and TANTSTA2

TANTSTA1 is used to specify a list of stations for which TANT1 will turn on and off Ta measurements. These stations must have Green Bank or snap type files, or SCHED will abort. TANTSTA2 specifies the stations whose antenna measurements are controlled by TANT2.

As noted in the discussion of TANT1, the only station that retains the capability for SCHED to request Tant measurements is Green Bank.

Argument: A list of station names of up to 8 characters each. Should match names of stations used in the schedule.

Options: Any station names. Unrecognized names will be ignored.

Default: Any stations in the schedule that have NRAO or SNAP control file types.

Usage: Only one list, the last given.

Example: TANTSTA1=’BONN’,’JODRELL’ tantsta2=nrao

TAPE

TAPE is an obsolete parameter now that tape is no longer in use.

TAPE requests that SCHED force a tape change at the start of the scan. This will override any automatic tape changing that is going on and will reset the reference time for any following automatic tape changes. If no argument is given, the tape will be changed at all stations. If a list of stations is given, the tapes will only be changed at those stations; if a station is given that is not in the scan, an error message will be generated and SCHED will abort. Station codes my be used in place of station names.

For stations that only have one tape drive (all except the VLBA and VLA), be sure to allow enough idle time to complete the tape change. This usually means 15 minutes and SCHED will issue warnings if it is less than this. Some stations claim to be able to do it in 10. If postpasses are required, and they are currently (Feb 1997) being done at thin tape stations, an additional up to 33 minutes is required. The station operators can override the postpass to save time, at the risk of damaging tapes which cost over $(US)1000 each. An alternative is to schedule the last pass at such stations without stopping the tape. If SCHED detects that this has been done, it will issue an UNLOAD command instead of POSTPASS. Note that the automatic postpass will only be requested at sites using VLBA control files. The VEX format does not (yet) include this concept.

Argument: None or a list of up to 30 station names.

Options: No argument or a list of any stations in the scan. Not case sensitive.

Default: Not used. Automatic tape changes by default.

Usage: Must specify whenever needed.

Example: TAPE or TAPE=VLBA_MK,VLBA_NL

TAPEFILE

TAPEFILE gives the name for the tape initialization file. See Section 3.4 for content details. The alternative is to have the tape initialization details imbedded in the SCHED input following TAPEINI or to use the defaults which are fine for the VLBA.

Note that a tape initialization file is almost certainly NOT needed. Most parameters in it relate to initial tape head and pass positions which no longer make sense in the disk era. The one possibly useful parameter is the media specification, but that should be defined in the station catalog and would only be used during periods of transition.

Under unix, environment variables may be used.

Argument: A file name of up to 80 characters.

Options: Any file name.

Default: ’NONE’, causing defaults or parameters specified after TAPEINI to be used.

Usage: Only one accepted, the last.

Example: TAPEFILE=’vlba.head’

TAPEINI

TAPEINI is a flag to inform SCHED that the next group of input parameters will be tape initialization information, equivalent to one line from the TAPEFILE. See Section 3.4 for content details. Once the tape initialization parameters have been read, SCHED will return to reading the inputs for the current scan, usually the first.

Note that a tape initialization file is almost certainly NOT needed. Most parameters in it relate to initial tape head and pass positions which no longer make sense in the disk era. The one possibly useful parameter is the media specification, but that should be defined in the station catalog and would only be used during periods of transition.

Argument: None.

Options: None.

Default: Not used.

Usage: Should not be used more than once.

Example: TAPEINI /

TAPESYNC

TAPESYNC is an obsolete parameter left over from the tape era.

TAPESYNC requests that SCHED try to synchronize tape changes at the stations. This is advisable to avoid slightly staggered tape changes that would naturally result from a subarrayed schedule. Such staggered tape changes can result in lost data because there is a minimum of about 3 minutes per correlator job and a new job is needed when a station changes tape. This is a temporary restriction but was in effect in late 1996.

WARNING: TAPESYNC could cause very strange behavior if used with a schedule in which some stations are being scheduled separately from others. It should only be used when the scans as specified to SCHED are in roughly time order (for subarrays, there can be small deviations from time order and that will be ok). It is only recommended for use in conjunction with the optimization options. For any schedules in which every scan is specified in the input, it would be best to use TAPE to force the tape changes at reasonable times, if necessary.

Also, be sure that any automatically generated tape change requests occur at times with sufficient gaps at single tape stations (all except the VLBA and VLA). See the discussion of TAPE for details.

Note that, with automatic tape allocation, SCHED does not set the tape change times so TAPESYNC will have no effect.

Argument: None.

Options: None.

Default: Not used.

Usage: Last value used.

Example: TAPESYNC /

TAVLBA and NOTAVLBA

TAVLBA tells SCHED to write a VLBA antenna-temperature measuring sequence in the VLBA control file for this scan. NOTAVLBA tells SCHED not to write such a sequence. Parameters PTSLEW and PTDUR are used as they are for PTVLBA. If antenna temperature measurements are desired as part of a VLBI project, a separate scan with TAVLBA set should be requested before or after the main VLBI scan. Do not rely on a long PTSLEW to get the VLBI data since during the setup part of the scan, the requested pointing position is at a half power point.

Use of TAVLBA is not the recommended calibration method for the VLBA. The apriori gains should be used instead. The VLBA antennas are not set up for accurate single dish measurements. The a priori values were obtained during good weather when this is not so much of a problem. If the weather is good for the VLBI project, the a priori values will be good to a few percent, probably better than any Ta measurement. If the weather is poor, the Ta measurements will probably be nearly useless.

This has no effect on VEX files.

Argument: None.

Options: None set. NOTAVLBA to go back to non-pointing modes.

Default: Not used.

Usage: Reverts to previous scan if not specified.

Example: TAVLBA

TELEX

TELEX is the Principal Investigator’s TELEX number for the cover information. This parameter is still provided only for backward compatibility. Don’t bother with it. Are telexes still in use?

Argument: Text of up to 64 characters.

Options: Any.

Default: Blank.

Usage: Only one value used, the last.

Example: TELEX=’+1-910-988-1710’

TPREF

TPREF is obsolete for the vast majority of users because Mark II systems were abandoned long ago.

TPREF is the reference time for Mark II tape changes. When automatic tape changes are specified, as is done by default, they will occur at times that are an integral number of tapelengths (default 4 hours) before or after this time. Since the only really valid Mark II tape length of 4 hours divides a 24-hour day evenly, no provision is provided to specify a day.

Argument: A time.

Options: Any valid time between 0 and 24 hours.

Default: Not used; rather start time of earliest scan of the schedule is used.

Usage: Only one value accepted.

Example: TPREF=5:0:0

TSYS and NOTSYS

This is an obsolete parameter because it only affected the Green Bank control files and the SNAP file, neither of which is now in use. Note that the GBT now does continuous system temperatures in the same manner as the VLBA.

By default, SCHED requests that system temperatures be measured every scan in the NRAO (Green Bank) and snap control file types. The VLBA measures Tsys continuously so no such request is needed. For Green Bank, the system temperatures are measured at the start of every scan (as part of the “MARKIII” procedure). They are no longer measured at the end of a scan. For stations using snap files, there is no concept of “go to source, then do something”, so Tsys requests are only made at the end of each scan. NOTSYS turns off the Tsys requests (For Green Bank, it also turns off all other actions included in the “MARKIII” procedure which might include antenna temperature measurements and peaking up pointing). The Tsys measurements take a bit of time so it may be desirable to turn them off when switching rapidly between sources; however, by doing so, calibration may be compromised. The measurement of system temperatures can be turned back on with TSYS.

This has no effect on VEX files; system temperatures are measured by PCFS controlled at the beginning of every scan. Note that with thin tapes and fan-out, the time between measurements could be as long as 44 minutes. SCHED will warn if there is more than 30 minutes between Tsys measurements for PCFS systems, except on a last reverse scan which may be forced to be long in order to avoid post-passing.

Argument: None.

Options: Use it or not.

Default: Ask for system temperature measurements.

Usage: Defaults to previous scan.

Example: NOTSYS

UVMFS

UVMFS affects UV plots, allowing the user to show the effect of using multi-frequency synthesis. The first argument is the number of tracks to plot per baseline. The default is to plot one with UV in km. The second argument is the ratio of the highest to the lowest MFS frequency. The UV values will be in km the middle of the frequency range.

This option could have been implemented by paying attention to the frequencies in the setup file, and that option should be added some day. But that requires either fully specified setup files, or freq.dat entries for all stations. When SCHED is being used for configuration studies, this is an undue burden.

Note that this is also used for the UV coverage based quality measures used for configuration studies.

Argument: Two numbers.

Options: The first number is converted to an integer. The second is a real and should be between 1.0 and about 2.0, although it is unrestricted

Default: 1 and 1.0 — meaning only plot one track per baseline.

Usage: One value used for schedule

Example: UVMFS = 5, 1.3

VERSION

VERSION Version number of the schedule for the cover information. Usually this will be 1 for the first, 2 for the second, etc. Often stations get a schedule, then the PI changes his/her mind about something, or finds and error, and so creates a new version. Later at the station, it is not always obvious which is the latest version. This version number is meant to make it obvious. SCHED will abort if VERSION is not specified.

Argument: Any real number, with decimals is desired as it will be printed in F10.2 format.

Options: Any but integers are typical.

Default: 0 which causes SCHED to abort.

Usage: Only one value used, the last.

Example: VERSION=1

VEXTEST

VEXTEST is a switch that allows testing of VEX related features that have not been released for public use. It is likely to only be of interest to the SCHED developers, although it is possible that early users of new features may need it.

Argument: No argument - this is a logical

Options: No arguments

Default: Not set, which may block some VEX features.

Usage: Only last value specified will be used

Example: VEXTEST

VLABAND and VLABW

These are obsolete parameters that specified the VLA observing mode and the VLA backend filter width. They should now be specified in the setup file. Any values specified in the main input will be ignored.

VLAINTEG

Obsolete for current VLA.

VLAINTEG is used to set non-standard integration times in VLA schedules. This would be useful mainly to influence the speed with which the system phases up. The argument is in seconds. The default is 10 seconds. SCHED generates //DS cards for all scans after a VLAINTEG is specified.

Argument: Integer between 0 and 999.

Options: See list above.

Default: 10 seconds.

Usage: Defaults to previous scan.

Example: VLAINTEG=3

VLAMODE

VLAMODE is used to control phasing up of the VLA. The control can also be done directly by specifying the phasing related INTENTs, but that can be more cumbersome, especially if other INTENTs are changing from scan to scan. A phasing mode is required. For a schedule using the VLA, if SCHED does not get a VLAMODE or a phasing related INTENT, it will quit. When VLAMODE is used, SCHED will generate the appropriate INTENTs for the VEX file for the VLAMODE that is given.

VLA reference pointing and array phasing must not be requested in the same scan.

The valid VLAMODE values are:

- Do not apply or determine phases. This generates INTENT = VLA:AUTOPHASE_OFF.
’VA’ - auto phasing on all IFs. This generates INTENT = VLA:AUTOPHASE_DETERMINE.
’VX’ - Apply phasing determined in previous VA scan.) This generates INTENT = VLA:AUTOPHASE_APPLY.
’VS’ - single antenna VLBI (not available on EVLA as of 2014). May want this to keep the phase center at the antenna if at all possible. This could generate INTENT = VLA:SINGLE_DISH.

Argument: Text of 2 characters.

Options: See list above.

Default: None - required for VLA.

Usage: Defaults to previous scan.

Example: VLAMODE=’VX’

VLAPEAK

VLAPEAK is used to control reference pointing on the VLA. The user will need to provide a scan of at least 2.5 minutes on a calibrator on which the pointing can be done. The observations should be at X band. These scans can be inserted explicitly, or AUTOPEAK can be used to insert them automatically (maybe not yet). SCHED will create appropriate INTENTs for the VLA scans based on the value of VLAPEAK. It is not recommended that the user attempt to specify the pointing related INTENTs explicitly although that is not prevented. If that is done, there can be interactions with the defaulting when other, unrelated INTENTs are used.

The four settings for VLAPEAK situations of interest are:

’DETERMINE’ indicates that the reference pointing corrections should be determined starting from no offsets. This sets INTENT = VLA:REFERENCE_POINTING_DETERMINE
’APPLY’ indicates that the most recently determined reference pointing offsets should be applied. This sets INTENT = VLA:REFERENCE_POINTING_APPLY
’ADJUST’ indicates that reference pointing corrections should be determined starting with the previously determined values. The results that can be applied to later scans are the sum of the previous and the newly determined values. This sets INTENT = VLA:REFERENCE_POINTING_ADJUST
’OFF’ indicates that no reference pointing offsets should be applied and that no attempt should be made to determine them. This is the default and is what will be used at all but the highest frequencies. This sets INTENT = VLA:REFERENCE_POINTING_OFF

A pointing pattern can be done if in a scan if there are at least 150 on source. Only one pattern is done, so adding significantly more time is not useful (unlike the old VLA system).

Reference pointing is important for observations at 1cm (K band) and higher frequencies (ie Q band). It might be useful at the high end of the 2cm (Ku band) range. For more information about reference pointing on the VLA please see the Guide to Observing with the VLA section on High Frequency Observing Strategy. The pointing should be done at C or X band, with X band recommended.

VLA reference pointing and array phasing must not be attempted in the same scan. SCHED will abort if that is tried.

Argument: Text of up to 9 characters.

Options: See list above.

Default: ’OFF’.

Usage: Defaults to previous scan.

Example: VLAPEAK=’APPLY’

VLAPTIME

On the VLA, a SCHED scan intended for array phasing is broken into subscans for purposes of obtaining phasing solutions at one solution per subscan. At least 4 subscans are required to obtain reliable phases. The length of the subscans can be set separately for each scan using VLAPTIME whose argument is in integer seconds. The default of 10 seconds will be good in most cases. Longer times can be used if a weak calibrator must be used or perhaps when phasing while recording on the VLBI target source. The subscan length is passed to the VLA through the VEX file in an INTENT that is created by SCHED.

Argument: A time in integer seconds.

Options: Any time over 10 seconds.

Default: 10 seconds

Usage: Defaults to previous scan’s value.

Example: VLAPTIME=20

VLATSYS and VLANTSYS

Obsolete for current VLA.

The VLA on-line system normally applies a Tsys-based amplitude correction to data from the VLA correlator. In order to calibrate 3-antenna and phased VLA data taken with the VLA as a VLBI station, it is necessary to have raw correlation coefficients. If the Tsys correction is made, the raw correlation coefficients are lost. The old DEC10 scheme for obtaining the VLBI calibration data was based on the standard VLA correlator output as archived, so it was necessary to request that the Tsys correction be turned off. The new scheme for obtaining the VLBI calibration information involves extraction of the correlation coefficients by the on-line system before the Tsys corrections are made. Therefore it is no longer necessary to turn the corrections off and leaving them on makes it easier to use the VLA correlator data to make VLA images. The default action of SCHED is now to leave the corrections on and that should be correct for essentially all observations. However, VLATSYS and VLANTSYS can be used to turn the corrections on and off, respectively, on a scan basis just in case someone still wants to do so.

Argument: None

Options: No value (a non-zero value turns has the effect of the opposite parameter)

Default: Keep Tsys corrections on.

Usage: Defaults to previous value.

Example: VLANTSYS or VLATSYS

VLAPSRC

This parameter was developed originally for the old VLA system. It has not yet been converted for use with the VLA. But that is on the to-do list.

VLAPSRC can be used to specify the source to use for phasing the VLA. If the scan is mode VX and VLAPSRC differs from SOURCE, then a scan will be inserted in the VLA observe file in VLAPSRC with mode VA. The VLBI control file will not be affected. The stop time of the phasing scan will be 1 minute before the start of the VLBI scan or 3 minutes after the stop of the previous VLBI scan, whichever is later. If less than 2 minutes of the VLBI scan remain as a result, a complaint will be generated. It is wise to take the VLA observe file into the NRAO VLA OBSERVE program to check the slew and dwell times, since the default timing used for VLAPSRC will not always be reasonable and the phasing scan stop time may need to be adjusted. Note that, since SCHED does not generate a phasing scan for a mode VA scan or when VLAPSRC equals SOURCE, VLAPSRC need not be specified or changed for such scans; this may minimize the number of times VLAPSRC needs to be specified.

Argument: Any source name of up to 8 characters.

Options: Any source in the catalogs. ’ ’ resets to use SOURCE and turns off the special phasing scan.

Default: Uses SOURCE, which causes no phasing scan to be written.

Usage: Defaults to previous scan.

Example: VLAPSRC=’0255+164’

VLARFANT

Obsolete for current VLA.

VLARFANT can be used to specify the reference antenna for the VLA. This will be the antenna used as the source of data in single dish VLBI. For the phased array, it will be the reference antenna for the calibration solution for phasing. Note that, in phased array mode, the phase center is always at the normal VLA phase center. In single dish mode, if there are multiple antennas available to the VLA correlator, they will be correlated with the phase center at the reference antenna. This is needed so for the old VLA system so that the fringe rotators do not affect the single dish VLBI data.

Normally the reference antenna is number 10, which is the default. If that needs to change, it is unlikely that users will be aware of that fact in time to change their schedule, so either SCHED needs to be rerun by operations with the new value, or the observe deck needs to be edited. Users in the vast majority should not worry about this parameter.

Argument: An integer between 1 and 28

Options: Any intger, specifying an antenna, between 1 and 28

Default: 10

Usage: Use only once.

Example: VLARFANT=15

VLATYPE

Obsolete for current VLA.

VLATYPE specifies the type of the observation for the VLA observe file.

Argument: Text of up to 9 characters.

Options: ’VLBI’ - VLBI observation. ’CONTINUUM’ - normal VLA continuum observation. ’LINE’ - VLA spectral line observation.

Default: ’VLBI’

Usage: Use only once.

Example: VLATYPE=’CONTINUUM’

VLAUSERN

Obsolete for current VLA.

VLAUSERN is the VLA user number. Provide the PI’s VLA number (same as the Socorro AIPS number) if desired. For VLBI runs the default of 600 is fine.

Argument: Integer.

Options: Any VLA user number.

Default: 600

Usage: Only last value entered is used.

Example: VLAUSERN=332

WRAP24

WRAP24 is a switch to aid VLBA operations in dynamic scheduling of 24 hour projects. For such projects, it is useful to be able to start at a time of day different from what the user specified. This is facilitated by the parameters WRAP24 and DOSCANS. Specifying WRAP24 with no argument causes SCHED to duplicate the schedule on a second day to form a 48 hour schedule. Actually it would duplicate any schedule, but it is mainly useful for 24 hour schedules. The full 2 day (or whatever) schedule shows up in the summary .sum file. Then DOSCANS can be used to select the desired 24 hours (or whatever time).

Note that this command has nothing to do with cable wraps. SCHED does not yet have control over cable wraps — it only tries to predict them.

Argument: No argument

Options: No argument - actually anything but -9999 will have the same effect

Default: Do not wrap

Usage: Will take one specification for the observation

Example: WRAP24

YEAR

YEAR specifies the year of the stop time of the scan. This must be specified for the first scan. It is possible to specify it more often, but that will almost never be necessary.

Note that two digit years will work for years between 1950 and 2050, but are not recommended.

Also, SCHED will complain about an unreasonable year if it is not between 1900 and 2100.

Argument: Integer.

Options: Any valid year.

Default: None - SCHED will stop if not given for first scan.

Usage: Defaults to previous scan.

Example: YEAR=1996

3.2 Source Catalog

SCHED uses catalogs to get source information such as names, positions, and velocities. These catalogs are in keyin format. Entries are terminated with a “/”. Some or all of the catalog may be included in a section in the SCHED input file. SCHED will look there first for sources, and then go to the two possible external catalogs to find the rest (or all). Please note that the source catalog, along with the locations catalog of station positions, is updated approximately annually to new solutions. All source positions will change, although likely by small amounts. But relative astrometry projects should either use their own source positions to keep them constant over long times, or include processing steps that account for any changes in the catalog positions (the preferred solution).

As of Feb. 2015, there are two catalogs (plus older versions) included with the SCHED distribution. One contains a recent astrometry solution from the Goddard Space Flight Center geodetic group. There is a symbolic link to it called sources.gsfc in $SCHED/catalogs. Another contains a recent solution provided by Leonid Petrov. The symbolic link for the latest of these is sources.petrov. The Petrov file typically has very nearly all of the sources in the Goddard solution (they are working from the same data sets) plus a significant number more — over 9000 in total. There used to be a third file, sources.vlba that contained all sources in either of the above plus around 500 others from JVAS and an old VLA calibrator list. As the first two lists got large, the remaining extra sources in sources.vlba become more suspect as VLBI targets. Plus maintenance of the combined list was somewhat problematic, so it was dropped in Feb. 2015. If there is a sources.vlba in the distribution, it is either out of date, or is actually a symbolic link to one of the main files, put there to try not to break old schedules.

The sources in the catalogs from the geodetic solutions are based on the International Celestial Reference Frame version 2 or ICRF2 (these have CALCODE=V). These have positional errors of a fraction of a milliarcsecond to a few milliarcseconds. They include sources from the standard geodetic observing program, sources from the VLBA calibrator survey, the Australian LBA survey, and various sources specially observed in the RDV project on the VLBA.

Users of accurate positions from the geodetic catalog are encouraged to reference the original papers, some of which are listed in the catalog headers. Information about, and data from, the GSFC solutions can be found at http://vlbi.gsfc.nasa.gov/dataresults_main.htm. Catalogs and much other useful information provided by Leonid Petrov can be found at http://astrogeo.org/.

SCHED input parameters SRCFILE and SRCFILE2 are used to point to any desired external catalogs. A file name of up to 80 characters can be specified. The default source file is:

SRCFILE=$SCHED/catalogs/sources.petrov.

On unix systems with the environment variable SCHED properly defined, this is the standard catalog distributed with SCHED. Users of the html version of the manual can read the catalog by clicking GSFC or Petrov.

Source catalog information can be given in the main SCHED keyin file. If the keyword SRCCAT appears, all input after the next “/” is assumed to consist of source catalog entries until a line containing the keyword ENDCAT and a “/” is encountered (don’t combine this keyword with a catalog entry). Such “in-line” catalogs may appear anywhere in a SCHED keyin file, although it is probably best to put them near the beginning. SCHED will look in the external catalog for any source not found in an in-line catalog. If you wish to prevent SCHED from looking in external catalogs, specify SRCFILE=NONE (SRCFILE2 is not used at all unless specified.). It is common to provide in-line source catalog entries for unique program sources, but let SCHED find the fringe finders and other calibrators in the standard catalog. SCHED will look in the in-line catalog first, then in SRCFILE, then in SRCFILE2. It will use data from the first place a source is found.

The parameters for each entry in the source catalog are below. Lower case letters in this list are optional. All catalog parameters except EQUINOX and EPOCH revert to a default unless specified for a source. EQUINOX and EPOCH default to the last specified.

Note that the plotting capabilities of SCHED, specifically the RD plots, can be used to examine the distribution of sources in the catalog and to find catalog near any desired location. This is useful, for example, for finding phase calibrators near target sources.

SCHED will use whichever equinox coordinates are provided in the catalog and determine J2000, B1950, and DATE coordinates. All of these coordinates are listed in the .sum file. Various stations require different equinox coordinates. For example, the VLBA only understands J2000 coordinates while some other sites only understand B1950, although those may all be gone by now. Sched uses the SLALIB routines to make the coordinate conversions.

The J2000 and B1950 coordinates systems move relative to each other so an “observe” date is needed to make an accurate conversion. This is the date at which the coordinates of the reference sources were determined. For example, the VLA calibrator list coordinates were determined in 1979.9 originally, and all subsequent updates, based mainly on J2000 positions, were precessed to B1950 using an assumed “observe” date of 1979.9. A similar situation exists at MERLIN, where observing is done in B1950 coordinates. There, the calibrator positions (based again on positions provided originally in J2000) are precessed to B1950 using an “observe” date of 1950.0. Any B1950 source position determined on MERLIN should be precessed to other systems using that date. The user can specify the “observe” date using the main schedule parameter PRECDATE which defaults to 1979.9, the correct value for use with B1950 source positions determined on the VLA. For purposes of pointing antennas, the value of this date that is used is not very important. But if you are trying to phase reference, phase the VLA at a high frequency, or derive positions for correlation, this is an issue that should be dealt with properly.

The parameters of the source catalog are:

Source:
This is the name of the source. Up to 10 source names (increased from 5 on Sept. 2010) can be provided to handle aliases. The names can have up to 12 characters each, although, as noted below, some downstream software may not like that much. No software we know of requires less than 8 characters.

Be a bit careful about special characters included in source names. Some are benign. But, for example, the * and ? characters are used as wild cards in many programs so, if either ends up in a file name (as it will after SPLIT in AIPS), it could cause problems. The temptation to use * is high because of sources such as SgrA*. But the conservative approach is to avoid it. Also, do not include imbedded blanks in source names, as they cause problems at a variety of places in processing. Minus signs (dashes), plus signs, underscores, and parentheses should not cause problems and are the commonly desired characters.

Note that the number of characters you can have may be limited by downstream software. Snap files require source names of 10 characters or less, but are not normally written by SCHED any more. Finally, beware that the Mark III correlators and the geodetic software have 8 character source name limits.

Ra:
Right ascension. Remember that the VLA and Westerbork need sub-arcsecond positions for phasing.
RAERR:
The coordinate error in the RA direction in but in milliarcseconds. Note that for RA, this is 15 times the coordinate value error. It is the coordinate error in the sense that, to get the position error in angle on the sky, one would need to divide by cos(Dec). Prior to Dec 2014, this manual description indicated that RAERR was the angle on the sky, but in practice for some time before that (forever?), it had been the coordinate error in milliarcseconds.
Dec:
Declination.
DECERR:
The angular error in the declination direction in milliarcseconds. For dec, this is the same as the coordinate error.
EQuinox:
Epoch of the observations. Allowed values are B1950, J2000, and DATE.
Calcode:
Single-character calcode used for VLBA control files. It is used by postprocessing packages to identify types of sources, usually types of calibrators. The CALCODE is optional for SCHED. CALCODE=’G’ is reserved for pulsar observations. This calcode will trigger the use of the pulsar gate on the VLBA correlator. Think of G as “Gate”. CALCODE=’L’ triggers on-line/off-line channel differences to be used for pointing data analysis. CALCODE=’Z’ indicates that the source is a satellite and that ephemeris data are needed for correlation (SCHED will set this one for any satellite).
VElocity:
Velocity (km/s) of a spectral line source. Up to 8 (16?) values can be given, one per base band channel. The value for the first base band channel will be used for any other channels for which no velocity is specified. The reference frame (eg LSR, Heliocentric...) and definition (radio, optical or redshift) are given by VREF and VDEF.
VRef:
The reference frame for velocity calculations. Supported options so far are ’L’ for LSR, ’H’ for heliocentric and ’G’ for geocentric. LSR is the default.
VDef:
The definition of the velocity. Supported options are ’R’ for radio definition (V = c(ν0 - ν)∕ν0), ’O’ for optical definition ( V = c(ν0 - ν)∕ν = c(λ - λ0)∕λ0 = zc ), and ’Z’ if the redshift is given directly. The default is the radio definition.
PMEPOCH:
For planetary motion, the offset from the RA and DEC are assumed to be zero at this time. The format is PMEPOCH = yyyy,mm,dd,hh:mm:ss; for example, PMEPOCH = 1995,12,7,15:0:0 for 15 hours UT on 1995 December 7. I appologize for any confusion caused by PMEPOCH not being the zero time for PMRA and PMDEC instead of DRA and DDEC. The SCHEDusage for planetary motion was established long before the proper motions were added to the program and I did not want to change the meaning of PMEPOCH. Also EPOCH is the standard throughout astronomy for the zero time of proper motion, which is why it’s meaning was changed from what is now EQUINOX.
DRA:
Rate of change of RA in seconds of time per UT day. This acts in coordinates of date. Note that this is the rate of change of the coordinate value, not the angular rate which would be smaller by cos(dec). The zero offset time is given by PMEPOCH. Use DRA and DDEC for fast moving objects like planets. Use PMRA and PMDEC for slow moving objects like stars.
DDEC:
Rate of change of DEC in arcseconds per UT day. Note that the azimuth and elevation reported by SCHED will not take into account DRA and DDEC. This acts in coordinates of date. The zero offset time is given by PMEPOCH.
PMRA:
The proper motion in RA in milli arcseconds per year. This is an angular value and is 1/cos(dec) times the change in coordinate value. The zero offset time is given by EPOCH. When PMRA, PMDEC, or PARALLAX is used, the source coordinates are shifted from the time specified by EPOCH to a time that is the stop time of the first scan or, if it is given, PMEPOCH. PMRA, PMDEC are added to DRA and DDEC respectively so that small motions during the observation of fast moving stars can be accommodated. The proper motion and planetary motion parameters can both be used together, if one is mad enough to want to do so.
PMDEC:
The proper motion in Dec in milli arcseconds per year. The zero offset time is given by EPOCH.
EPoch:
The zero point for proper motion expressed as a fractional year such as 1993.6.
PARALLAX:
The parallax in milli arcseconds. Synonym PARALAX for backward compatibility (yes, I misspelled it the first time so backwards compatibility is an issue).
FLUX:
Flux densities at up to 10 frequencies for the source. The arguments (up to 30) are in triplets with the first being the frequency in GHz, the second is the total flux density in some image, and the third is the unresolved (peak) flux density — what you are likely to see on long baselines. These values are typically taken as a byproduct of geodetic observations and should be taken as approximate. All compact source vary to some degree — most by a lot — so the source may well prove to have a different strength when used than is shown. But these flux densities should help distinguish the strong from the weak calibrators.
FLUXREF:
A text string that indicated where the flux density information came from. It is likely to match one of the catalog names from which positions of some sources were obtained. It may not match the position catalog for an individual source. A typical case, at the time this parameter was added, is that the flux densities come from one of Petrov’s catalogs while many of the sources use positions from a GSFC solution.

Below is a sample of a few sources from the March 2005 source catalog, slightly reformatted to fit the page width.

SOURCE=’J1629-2026’  
     RA=16:29:03.0298580 DEC= -20:26:55.100570  
     RAERR=  29.510 DECERR=  13.450 CALCODE=’V’  
     REMARKS=’VLBA Calib Survey - GSFC sols. - VCS2 - created 2004’ /  
SOURCE=’J1630+2131’,’1628+216’  
     RA=16:30:11.2308370 DEC=  21:31:34.310260  
     RAERR=   4.370 DECERR=   5.380 CALCODE=’V’  
     REMARKS=’VLBA Calib Survey - GSFC sols. - VCS2 - created 2004’ /  
SOURCE=’J1631+1052’,’1628+109’  
     RA=16:31:18.7777000 DEC=  10:52:02.460000  
     RAERR=   4.370 DECERR=   5.380 CALCODE=’M’  
     REMARKS=’JVAS-Browne etal. 1998, mnras, 293, 257; S8.4GHz= 72 mJy’ /  
SOURCE=’J1631+4927’,’1629+495’  
     RA=16:31:16.5398860 DEC=  49:27:39.515680  
     RAERR=   0.520 DECERR=   0.630 CALCODE=’V’  
     REMARKS=’VLBA Calib Survey - GSFC sols. - VCS2 - created 2004’ /

3.3 Station Catalog and Locations Catalog

SCHED uses a catalog to get station information such as names, positions, horizons, slew characteristics and more. This catalog is in keyin format. Station positions may be stored separately in a Locations Catalog. There are standard Station and Location Catalogs which will almost certainly have all stations used by a project. SCHED will find these catalogs by default or their locations may be specified. Any or all of the Station Catalog entries may be given in the main SCHED input if desired. In any case, the scheduler should consult the catalog to be sure that the right station names are being used in the schedule. The catalog associated with this release of SCHED is at $SCHED/catalogs/stations.dat.

SCHED input parameter STAFILE is used to point to any desired external catalog. A file name of up to 80 characters can be specified. The default is the standard catalog for digital backends:

STAFILE=$SCHED/catalogs/stations_RDBE.dat. Eventually that will be set back to STAFILE=$SCHED/catalogs/stations.dat once the conversion of documentation and examples is complete.

Station catalog information can be given in the main SCHED keyin file. If the keyword STACAT appears, all input after the next “/” is assumed to consist of station catalog entries until a line containing the keyword ENDCAT and a “/” is encountered (don’t combine this keyword with a catalog entry). Such “in-line” catalogs must appear in the SCHED keyin file before the all of the input for the first scan is complete. This allows the use of station codes to specify stations in each scan.

Both in-line catalog entries and an external catalog may be used for the station catalog. This would mainly be useful if there is a non-standard antenna in the schedule. That antenna’s parameters can be put in the in-line catalog while all other antennas are picked up from the external catalog. If you wish to prevent SCHED from looking in external catalogs, specify STAFILE=NONE.

It is only necessary to give one of X, Y, and Z or ELev, LAT, and LONG. The missing set will be calculated. If both are given, the provided values will be used. If a conversion is done, the WGS84 ellipsoid is used and the calculations are accurate at the cm level. Since WGS84 is tied to the ITRF, this should be a good way to convert GPS coordinates to the Earth centered coordinates used in VLBI.

Some of the information that can be given in the station catalog can also be provided through a locations catalog. This is mostly position information. The locations catalog can be specified by LOCFILE. See the description of that parameter for a list of the station parameter that can be in the locations catalog. SCHED will read and store the locations catalog before reading the stations catalog. If the station position is missing from the stations catalog, SCHED will search for a station in the locations catalog with the name specified with DBNAME in the stations catalog. If a match is found, the associated coordinates will be used. The locations catalog is used because, in the standard catalogs, the station locations are from the VLBA correlator data base while all the other information is from other places. It is much easier to maintain separate catalogs. Users will probably not need to worry about all this, except perhaps to specify LOCFILE if they keep the SCHED standard catalogs in a non-standard place.

The parameters of the station catalog are given below. Items that can be in the locations catalog are noted. Lower case letters are optional. Entries for a station in the Station Catalog are terminated with a “/”.

Version and station names:

VERSION:
Catalog version. Actually set to the date when all the master catalog segments were last gathered to form a full catalog.
STAtion:
Station name. Up to 8 characters.
STCode:
Station code. Up to 3 characters. Usually there are 2 characters. See Appendix A.1 for a list of codes.
DBNAME:
The station name used in the VLBA correlator data base. Might not be the same as STAtion. DBNAME is used to associate entries in the locations catalog with station catalog entries. SCHED uses STAtion for almost everything else. This name distinguishes each pad of the interferometers. There is a matching parameter with the same name in the locations catalog. Up to 10 characters.
DBCODE:
The station code used in the VLBA correlator data base. May not be the same as STCode. SCHED uses STCode for almost everything. This code distinguishes each pad of the interferometers so contains more information than the usual 2 letter codes given in STCode. Can be put in the locations catalog.

Station location:

FRAME:
A character string indicating the origin of the station location information. Can be put in the locations catalog.
ELev:
Station elevation in meters above (mean?) sea level for geodetic coordinates or meters from the center of the Earth for geocentric coordinates; these cases are distinguished by value magnitude.
LAT:
Station latitude, either geodetic or geocentric. The format is dd:mm:ss. Positive in Northern Hemisphere.
LONG:
Station longitude, either geodetic or geocentric. The format is ddd:mm:ss. Positive in Western Hemisphere.
ZALim:
Zenith angle limit in degrees. Can be used to limit elevation coverage for stations with other than AZEL mounts. The antenna will be assumed to point below this limit to whatever limits are specified with AX1LIM and AX2LIM for purposes of slew calculations. However, if the antenna is below this limit, the source will be considered to be down during any optimizations.
X:
Station X coordinate in meters. This is in the direction of the Greenwich meridian. Can be put in the locations catalog.
Y:
Station Y coordinate in meters. This makes a right handed coordinate system with X and Z. Can be put in the locations catalog.
Z:
Station Z coordinate in meters. This is in the direction of the north pole. Can be put in the locations catalog.
DXDT:
Station rate of change of the X coordinate in meters per year. Can be put in the locations catalog.
DYDT:
Station rate of change of the Y coordinate in meters per year. Can be put in the locations catalog.
DZDT:
Station rate of change of the Z coordinate in meters per year. Can be put in the locations catalog.
EPOCH:
The epoch in MJD at which the X, Y, Z coordinates apply. In other words, when the offsets due to the rates is zero. Can be put in the locations catalog.
DEScrip:
Any text up to 80 characters (not used by SCHED).

Hardware types:

CONtrol:
Telescope control file type. VEX files are produced for all projects because most antennas are converting to using them for telescope control (including the VLBA) and most of the correlators (DiFX, JIVE, MarkIV) need such files to control correlation. Other CONTROL options imply that other format files are written in addition to the VEX file. Valid option are VLBA for VLBA control files, VEX for stations that don’t need any other formats, VLA for VLA observe files (obsolete), NONE for no control file - the default. A ’V’ in the 5th character will cause a VLBA control file to be produced with only the DAS (Data Aquisition System — BBC’s, formatter, recorder etc) parameters. It is meant for cases with a VLBA style VLBI backend, but something else for telescope control. If the first 4 characters are VLBA, this will be the only file. If they are something else, both the other type of file and the reduced VLBA file will be produced. This is the default when CONTROL = VLA.
DAR:
Gives the type of Data Acquisition Rack present. This is mainly to identify the type of formatter is at the station which will let the program know about the capabilities available. Valid types are: VLBA, RDBE, RDBE2, DBBC, MKIV, VLBA4, MKIII, S2, K4, K5, VERA, VSOP, LBA and NONE (the default). Note that for Mark II scheduling (now obsolete), any site scheduled will be assumed to have Mark II equipment. The main non-obvious option above is VLBA4, which is a VLBA DAR but with a Mark IV formatter installed. This will have VLBA BBC’s and IF switching, but Mark IV formatting characteristics. The RDBE and DBBC are digital systems containing FPGA chips that can support multiple personalities. Those personalities are specified in the setup file since they can change between schedules, or even scans. The personalities are specified with DBE setup file parameter.

The RDBE2 option is the same as the RDBE except that the presence of 2 RDBE units is assumed allowing twice as many channels with the DDC personality. To use 2 RDBEs with one MARK5C unit required the use of the VDIF format which is not yet available for the PFB personality. Also the PFB personality puts out a fixed 2 Gbps which is twice the capacity of the current MARK5C recorders.

DBBCVER:
Gives the version of the DBBC. Currently supported versions are:
RECORDER:
Gives the type of tape recorder(s) present Valid options are: VLBA, MKIV, VLBA4, MKIII, S2, K4, K5, VERA, VSOP, MARK5A, MARK5B, MARK5C, and NONE (the default). The VLBA4 option is for VLBA recorders which have been modified for 16 Mbps per track operation and can be equipped with 2 recording heads. They are usually associated with MKIV or VLBA4 DARs.
NBBC:
Tells SCHED how many BBC’s or VC’s are at the site.
NDRIVES:
Gives the number of tape drives at the sites. Most have only 1 but all VLBA sites, for example, have 2. This can be overridden for a schedule using the NDRIVES parameter in the tape initialization information. Note that, even with Mark5A disks, this may need to be set to 2 to allow 512 Mbps recording, which requires two heads or two drives to give 64 tracks. NDRIVES should be the maximum number of drives at the station. If less are in service, the tape initialization input, NDRIVES can be used to specify the smaller number. For S2 sites, NDRIVES should be the number of individual recorders.
NHEADS:
Gives the number of recording head blocks on each VLBA or MKIV drive. This will be useful mainly for MKIV (and VLBA4) which will at some point have 2.
DISK:
Used to indicate that a disk based recording system is available at the station. Which system to use depends on the value of the MEDIA parameter in the tape initialization information. For VLBA systems, commands for both RECORDER and DISK can be included in the control file. Valid arguments to DISK for now are restricted to MARK5A, MARK5B, LBADR and NONE (the default).
MEDIADEF:
Gives the default recording system to use. It can be overridden by MEDIA in the TAPEINI section. The options are TAPE and DISK. This is meant to facilitate VLBA operations during the transition from tape to disk.

Horizon:

HOR_AZ:
Up to 200 azimuths at which horizon elevations are given in HOR_EL.
HOR_EL:
Up to 200 elevations for the horizon at the azimuths specified by HOR_AZ. SCHED’s down, rise, and set notes will take these horizons into account. They will also be used in the optimization mode.

Mount details and performance:

MOUNT:
The type of mount. SCHED uses this, along with the axis limits and rates, to calculate slew times. The understood options are ALTAZ, EQUAT, XYEW and XYNS. Note that XYNS is for an XY axis system with the fixed axis in the north-south direction (for example, Fairbanks). XYEW is for the other orientation (for example, Hobart).
AXISTYPE:
The axis type as recorded in the VLBA correlator data base. There are different keywords here than for MOUNT. Some day this should be cleaned up. Can be put in the locations catalog. Will go to the VEX file.
AXISOFF:
The axis offset in meters. Can be put in the locations catalog. Will go to the VEX file for correlation.
AX1LIM:
The slew limits for the first axis which is usually azimuth, hour angle or X. The units are degrees for azimuth or X and hours for equatatorial mounts. There are up to 3 pairs of numbers giving the lower and upper limits for 3 different parts of the sky. This is required to describe the limits for the 140’ at Green Bank and for XY antennas such as Hobart. Only the first set will be used for altaz antennas. For altaz antennas, the zero for azimuth is to the north and positive is clockwise looking down on the antenna. For XY antennas, positive is to the north or east.
AX2LIM:
The slew limits for the second axis which is usually elevation, declination, or Y. The units are degrees in all cases. There are 3 pairs of numbers which define the three parts of the sky over which the 3 pairs of AX1LIMs apply. The ranges for altaz antennas should not overlap, although they can touch. For XY antennas, overlaps are ok.
AX1RATE:
The slew rate for the first axis in degrees per minute for all mount types.
AX2RATE:
The slew rate for the second axis in degrees per minute.
AX1ACC:
The acceleration for the first axis in degrees per second squared for all mount types. If one value is given, it is assumed to apply to both acceleration and deceleration. If two values are given, the first is for acceleration and the second for deceleration (although for the calculations, they are interchangeable).
AX2ACC:
The acceleration for the second axis in degrees per second squared. If one value is given, it is assumed to apply to both acceleration and deceleration.

Scan timing information:

TSETTLE:
The time in seconds (or mm:ss etc) to add to the slew time for dwell time scheduling to determine when the antenna is ready to observe. This will include any computer overhead, and time to make calibration observations. Acceleration and deceleration will be calculated explicitly if the above acceleration parameters are provided in the station catalog.
MINSETUP:
The minimum interval between scans when using dwell time scheduling. If the slew time plus the settling time drops below MINSETUP, MINSETUP will be used as the interval between scans. This is required because some antennas have a minimum scan setup time but the actions that take that time can overlap with the slew. When the slew is long, the extra time does not need to be added.
TSCAL:
Lets SCHED know when the station measures system temperatures. Arguments are text of 4 characters. The viable options so far are “gap” and “cont” that indicate the system temperature measurements, or at least cal measurements, are done in the gap between scans or continuously during observing. The VLBA uses an 80Hz cal switch and measures cal-on and cal-off powers from which, using a known cal temperature, the system temperature can be derived. Typical field system controlled stations fire the cal once at the start of a scan and measure the on and off power. SCHED will warn if there is inadequate time to do this if TSCAL=GAP, but not when TSCAL=CONT. This facility is still not fully installed as of Nov. 5, 2008.
MAXSRCHR:
The maximum number of sources per hour. This is originally intended to enable enforcement of the limit in the number of slews per hour on the Mark1 telescope at Jodrell. They are very worried about fatigue and will refuse to run fast switching schedules. The default is 1.E6 which should be more than anyone would try to schedule.
TLEVSET:
This is a time to be added to the slew calculation to allow for the set-and-remember power level adjustments that happen on the VLBA (RDBE) or VLA the first time a particular setup is seen. Like MINSETUP, the time can overlap with slews so functionally, this parameter acts exactly like MINSETUP but only for the first scan with a particular setup. The VLBA needs 15 seconds. The VLA needs 60 seconds. As of Nov. 2012, the VLA actually needs this every time there is a slight frequency change (like new Doppler shift), but we will try to get that changed to be only for more major changes. Note that, if the first scan with a setup is non-recording, non-pointing, and non-phasing, the scan itself will be accepted as the level setting (DUMMY on the VLA) scan. This allows for explicit insertion of DUMMY scans.

Below is a sample entry from the RDBE based version of the standard station catalog. The full catalog a can be examined here for the version that uses MARK5A at the VLBA and here for the RDBE based version.

 
 STATION=VLBA_MK   STCODE=Mk  CONTROL=VLBA  
    DBNAME = MK-VLBA  
    MOUNT=ALTAZ  AX1LIM=-90,450 AX2LIM=2.25,90 AX1RATE=86.8 AX2RATE=28.3  
    AX1ACC=0.75  AX2ACC=0.25  
    TSETTLE=6 TLEVSET=5 MINSETUP=5  DAR=RDBE  NBBC=16  
    DISK=MARK5C   MEDIADEF=DISK    TSCAL=CONT  
    ! MK    From 150 K Ts line by Beasley and Medcalf  Aug 1992.  
    HOR_AZ =   0,  5, 10, 15, 20,120,125,130,135,140,145,150,155,160,  
             165,170,175,185,190,195,200,205,210,215,220,255,260,270,  
             275,280,285,290,295,300,305,310,315,320,325,330,335,340,  
             345,350,355,360  
    HOR_EL =   5,  4,  3,  3,  2,  2,  4,  5,  5,  4,  4,  6,  8,  8,  
              11, 12, 13, 13, 11, 11,  9,  7,  5,  3,  2,  2,  3,  3,  
               5,  6,  8, 10, 12, 14, 12, 11,  9, 10, 11, 10, 12, 14,  
              12,  9,  7,  5  
  /  

3.4 Tape Initialization File

The tape initialization file is mostly obsolete. It is possible that the ability to select the media type for particular stations will be of use in the future during transitions between recording systems. But all tape positioning capabilities became obsolete along with the tape systems. The highly unlikely that a tape initialization section is needed in any schedule file. If one is present, it is probably an artifact of the use of old templates and it should be removed.

The tape initialization information can be used to select what type of recording to make at a station and to give details about the tape recordings if tape is used.

During the transition to Mark5, there was a period where both tape and disk systems will be available at stations. SCHED needs a way to select which to use. For each station, a default can be set with MEDIADEF in the station catalog. To override that default, the MEDIA parameter is provided here to tell SCHED whether to assume that the data transmission system is specified by RECORDER or DISK in the station catalog.

The following is retain for historical reasons and should not concern most users.

If you are not using the MEDIA parameter, then you almost certainly should not be using a tape initialization section TAPEINI or tape initialization file. All the parameters have good defaults for nearly all cases so explicitly setting them is more likely to get you into trouble than to help. The capability provided by the file is only retained for special test observations. Even the MEDIA parameter is not normally needed. If your SCHED input file contains a TAPEINI section, you are probably an old time VLBI observer using ancient templates.

When using a tape system, the tape initialization information tells SCHED details about the tapes to be used at each site. In nearly all cases, the defaults are appropriate and very few users need to specify any of this information. Other than for test observations which the user may wish to start in the middle of a tape, the only exceptions are for observations that use thick tapes on Mark III or Mark IV systems. But since such tapes are no longer allowed at most stations, this should be very rare. If tape initialization information is needed, the information can be specified in an external file, the TAPEFILE, or can be imbedded in the main file following the parameter TAPEINI.

The capability to have a separate TAPEFILE was originally part of an attempt to deal with the general case of VLBA tape handling. Such a file could have been used to schedule multiple projects per tape by specifying where each project starts. The file would have one full set of inputs per project. But the automatic tape allocation by the on-line system now deals with this situation in a cleaner manner. Automatic tape allocation and automatic reversals can be requested using SCHED’s AUTOTAPE parameter; however, these options only apply to sites with VLBA control systems and more than one tape drive and can only be used for projects to be correlated on the VLBA correlator. When automatic tape handling is requested, SCHED puts the appropriate commands in the control files. It also attempts to predict what the tapes will do assuming that they start in the place specified in the tape initialization file. Users should be aware that these predictions may be not be accurate because tape lengths can vary and the tape start position may depend on the preceding project.

Note that the number of heads in use at a time (8, 16, or 32), which determines the number of passes per head index position (1, 2, or 4 as specified by TPMODE in the setup file, is not allowed to change during a project at a station, although different stations may use different values for TPMODE. This restriction avoids a the bookkeeping nightmare raised by the more general case. SCHED checks all the requested setups for a station and remembers the largest number of heads (smallest TPMODE) and allocates tape for all scans as if that value were in use. This is wasteful of tape, but allows some tests to be done with mode switching.

The following are some capabilities supported through the tape initialization file:

  1. Different tape lengths at different stations.
  2. Different bit densities, and hence tape speeds, at different stations.
  3. Tape drive and index position at program start specified for each station.
  4. Tape speed, bandwidth, and sample rate can change during run. Beware of operational restrictions on the use of this capability. See the guidelines for preparing observing schedules available from the NRAO WWW home page under VLBA.
  5. Different number of tape drives at each station.

A single set of tape initialization conditions can be specified in the SCHED keyin file using TAPEINI followed by a “/”, in much the same way that in-line catalogs are given. This is the normal way that the tape initialization information is provided. Unlike the source and station catalogs, only one input group will be read and that group will be terminated by a “/”. No ENDCAT or equivalent is required, or even allowed.

The input parameters of the TAPEFILE are:

 

MEDIA:    Which record system to use.

 

NDRIVES:  Number of drives at the site.

 

NHEADPOS: Number of head positions in use at site.

 

OBSCODE:  Experiment code for this observation.

 

TPSTA:    Station name for this group of parameters.

 

TPDRIVE:  The drive to begin the observation on.

 

TPINDEX:  The tape index at which to start the observations.

 

TPLENGTH: The length of the tapes to be used at the site.

 

DENSITY:  Are tapes at sites high or low density.

 

TPTIME:   Mark II tape length in time.

 

HEADMODE: Indicator of head positions to use.

The first example shows a tapeini section that might be used during the transition to MARK5. Note that BOTH means create a schedule with both types of control information so that operations can pick which to use. This works for the VLBA, but not for stations controlled by the VEX file. For this example, all tape parameter will take their default values.

 
tapeini /  
tpsta    = vlba_sc, vlba_hn, vlba_nl, vlba_fd, vlba_la, vlba_pt,  
           vlba_kp, vlba_ov, vlba_br, vlba_mk, gb_vlba, medicina,  
           noto,    onsala60  
MEDIA    = TAPE,    TAPE,    TAPE,    DISK,    DISK,    DISK,  
           DISK,    TAPE,    DISK,    TAPE,    TAPE,    DISK,  
           TAPE,    DISK  
  /

The second example of a tape initialization group shows the usage for specifying the tape system. Note the NDRIVES is not given so that it is picked up from the station catalog. Note that the example file for VLBI at the VLA contains a tape initialization group to show what it is like. Usually it should be reasonable to take the defaults.

 
obscode =’default’  
tpsta   =’vlba’, ’vla1’, ’vla27’, ’eb_vlba’, ’gb_vlba’, ’default’  
tpdrive =1,      1,      1,       1,         1,         1  
tpindex =1,      1,      1,       1,         1,         1  
tplength=17600,  17600,  17600,   17600,     17600,     8800  
nheadpos=14,     14,     14,      14,        14,        14  
density =H,      H,      H,       H,         H,         L  
        /  

3.4.1 Details of Tape Initialization Parameters

MEDIA

MEDIA is used to specify how the data are to be transmitted to the correlator. This is mainly useful when a station has alternatives, such as both a tape system ( station catalog parameter RECORDER) and a disk system (station catalog parameter DISK) and the default needs to be overridden. Valid arguments are blank (use the default), TAPE (use the tape system), and DISK (use the disk system). Eventually other options such as real time may be added.

If an option is specified that is not consistent with what is available at the station, an error will occur.

Note that most, if not all, stations now have ways to convert tape to disk files so it is essentially never necessary to specify MEDIA, and, in fact, is essentially never necessary to have a tape initialization section.

Argument: An array of character strings of up to 8 characters each, one per station. Not case sensitive.

Options: One of Blank, TAPE, DISK, TAPEDISK, DISKTAPE. Must have corresponding RECORDER or DISK in the station catalog.

Default: TAPEDISK for the VLBA controlled systems, TAPE for others.

Usage: Defaults to the previous group.

Example: MEDIA=DISK, TAPE, TAPEDISK, DISK

NDRIVES

NDRIVES if the number of tape drives at each station. This parameter can also be given in the station catalog and only need be given here for abnormal configurations. The value in the tape initialization information will override the number in the station catalog.

The VLBA sites and the VLA normally have 2 drives. Other sites will usually have 1.

Note that the schedule can be forced to use a single tape drive other than number 1 by setting NDRIVES=1 and TPDRIVE=N where N is the desired drive (usually 2). This is useful if, for example, tape drive 1 is out of service.

For S2 stations NDRIVES indicates the number of transports in the S2 recorder (usually 8).

NDRIVES will not be allowed to exceed the number specified in the station catalog.

Argument: An array of up to 30 integers, one for each station in the TPSTA list.

Options: 1 or 2 are the likely choices.

Default: 2 for the VLBA and VLA, 1 for others.

Usage: Defaults to the previous group.

Example: NDRIVES=1,1,2,2,1,2

NHEADPOS

NHEADPOS is the number of head positions to use at the station. The traditional number for Mark IIIa sites is 12. However, the VLBA uses a head position sequence with 14 positions. This allows more data to be put on a tape. This input is provided mainly to allow the number of head positions to be forced to 12 to match a schedule made to allow time for tape changes every 12 head positions. This is likely to be common for Mark III projects.

The MkIV schedules are currently scheduled with similar transverse tape format as the VLBA; normally the same 14 head positions are used. For recordings made with 2 heads, 6 head positions is the default. For S2 recorders this parameter is ignored, the different groups in an S2 format can be set by TPMODE.

Argument: An array of up to 30 integers, one for each station in the TPSTA list.

Options: 12 or 14 are the likely choices but the program will take any value.

Default: 14

Usage: Defaults to previous group.

Example: NHEADPOS=12,12,14,14,12,14

OBSCODE

OBSCODE is the Project code for the project for which this group of inputs applies.

Argument: Character of length 8.

Options: Any valid project code.

Default: DEFAULT. Implies that this group will give the default information.

Usage: Defaults to previous group, which is not likely to be useful.

Example: OBSCODE=’BW005B’

TPSTA

TPSTA is an array of up to 30 station names. One can be ’DEFAULT’ which means that the corresponding parameters will be used for stations not explicitly in the list. A station VLBA will match any VLBA stations that are not specified explicitly. Actually it matches any stations with the first four characters “VLBA”. A station VLA matches any station with the first 3 characters “VLA” that is not otherwise specified explicitly. For example, it matches “VLA1” and “VLA27”.

Argument: Character of length 8.

Options: Any station name.

Default: Blank

Usage: Defaults to previous value if none are specified. This is likely to be the normal mode of use with the station list only given for the first observation. If any stations are given, it is assumed that a complete new list is being given.

Example: TPSTA=’VLBA_PT’,’VLBA_KP’,’VLA27’

TPDRIVE

TPDRIVE is the tape drive on which to start the project. Each element in the array applies to the station in the corresponding element in the TPSTA array. If NDRIVES=1, the schedule will use the tape drive specified by TPDRIVE for all scans. This is useful for cases when tape drive 1 is out of service.

Argument: An array of 30 integers.

Options: 1 or 2 for VLBA sites. 1 for most others.

Default: 1

Usage: Defaults to previous value.

Example: TPDRIVE=2,1,1

TPINDEX

TPINDEX is the head index position on which to start. It will be assumed that there are no previously recorded data at this index position. A value for each station in TPSTA. With the new head position sequence all forward passes start on odd numbered index positions. SCHED will require TPINDEX be odd and will add 1 to any even value.

Argument: An array of 30 odd integers.

Options: Integer between 1 and 13.

Default: 1

Usage: Defaults to previous value.

Example: TPINDEX=5,6,2

TPLENGTH

TPLENGTH is the length of the tapes in use at each site. For VLBA, Mark III, and Mark IV tapes, the length is in feet. Thick tapes, which are still in use within the EVN but are not allowed at the VLBA correlator, have roughly 8800 feet of usable length(see the section on tape lengths). Thin tapes used for most VLBA and Mark IV observations usually have 17600 feet of usable tape. The VLBA operations staff tries to make sure that all thin tapes have at least 17400 feet of usable tape by splicing in extra when needed. Note that the 200 ft difference amounts to 30 seconds at 80 ips (the speed for speed-up-factor 2 observations).

Note that changing the length of the tape is not sufficient to switch from thick to thin tape. In that case one usually also needs to modify the recording density

S2 tape length should be given in seconds, corresponding to Standard Play in a US VCR. A tape with label ST-120 (or SE-180) should be scheduled with TPLENGTH = 7200

Argument: An array of 30 integers giving tape lengths in feet.

Options: Any value, but 8800 and 17600 are likely to be the true values.

Default: 17600

Usage: Defaults to previous value.

Example: TPLENGTH=17600,00,8800

DENSITY

DENSITY specifies whether the tape is to be written at high or low density. The tape speeds corresponding to each density can be specified in the setup file using TPSPEEDH SP:TPSPEEDH and TPSPEEDLSP:TPSPEEDL or, better, they can be allowed to default.

For S2 tapes, density “H” refers to SLP and “L” to LP.

Argument: An array of character strings of up to 8 characters each, of which only the first character will be used.

Options: The first letter of each string must be “H” or “L” (not case sensitive).

Default: H for the VLBA and VLA, L for others

Usage: Defaults to the previous value.

Example: DENSITY=H,L,L

TPTIME

TPTIME. This is for Mark II. It specifies the reference time for tape changes at each site. The tapes at the station will be changed an integral number of 4 hour intervals before or after this time. In effect, it is a station dependent TPREF. This value, if specified, will override TPREF for the corresponding station.

Argument: An array of 30 times in hh:mm:ss format.

Options: Any valid time between 0 and 24 hours.

Default: -1 which causes it not to be used. TPREF or the first scan of the project will be used instead.

Usage: Defaults to previous value.

Example: TPTIME=2:0:0,3:0:0,2:0:0

HEADMODE

HEADMODE. This allows the user to set the head usage mode. Such a mode includes the head positions for each pass and the sequence of head positions to use for passes. There are two options and a default. Use of anything except the default (blank) is only recommended for system tests. The first option is VLBA14 which is the standard VLBA/MARKIV sequence with 14 head positions. The other option is MKIV2H which is appropriate for Mark IV wide band observations that use two headstacks. If MKIV2H is set by the user, or more likely by the program when in TWOHEAD mode, NEADHDPOS is forced to 6.

Argument: A character string of up to 8 characters

Options: ’ ’, ’VLBA14’, or ’MKIV2H’

Default: ’ ’, which tells the program to figure it out.

Usage: Defaults to previous value.

Example: HEADMODE=MKIV2H

3.5 Frequency Catalog

SCHED is able to fill in many items in setup files based on knowledge of possible frequency setups at the stations as described in the frequency catalog. This allows the user to only specify basic information. A reasonable minimum set is: NCHAN, BBFILTER, BITS, POL (can be DUAL), and either FREQREF (and FREQOFF) or BAND. The frequency catalog also allows SCHED to check user specified values against standard sets to warn of any oddities.

Most users will not touch the frequency catalog. If they need a setup that does not conform to what is in the catalog, they should just make the necessary setup files and ignore the warnings after making sure that the special files are correct. Be very careful doing this. There are filters on many of the LO and IF cables, at least on the VLBA, that most users probably are not aware of. Any special setup files that do not match one of the standards should be shown to Craig Walker for approval. If it is a good one, it may be added to the standards. However, the standard set is essentially complete for the VLBA. If SCHED complains about yours, it is likely to be in error. If a user really wants his/her own frequency catalog, use the input parameter FREQFILE to specify the file name.

There is a lot of information about available frequencies, receivers, frequency ranges, filters etc, especially at the VLBA, in the standard frequency catalog. A table of information about possible setups for observations within a frequency range can be made by running SCHED with FREQLIST = lowfreq, highfreq (eg freqlist=4800,8900) as the only input. The frequencies are in MHz. If only one frequency is given, the second will be set equal to the first. SCHED will produce a table in file frequencies.list containing details of the information available on how to set up these frequencies at all known sites. SCHED will then quit. Note that it is not necessary to transfer this information to your setup files — SCHED will do that automatically based on your frequency and polarization requests in the setup file. To examine the catalog itself, look at $SCHED/catalogs/freq.dat or, if reading the html version of the manual, click here..

3.5.1 List of Frequency File Parameters

The parameters of the frequency file tell SCHED over what frequency range the group if usable and on which stations. Most of the parameters are the same as parameters in the setup file since they are meant for direct substitution once the correct frequency group has been identified. There is no defaulting between groups of inputs — all parameters are reset to zero, blank, or some equivalent value.

For the VLA, IF’s A and C will be assumed to apply to VLA27 while IF’s B and D will be assumed to apply to VLA1. All standard frequency groups will have both VLA IF’s on the same frequency. Anything more complicated requires a setup file from the user.

STATIONs
Up to 10 stations with this setup. This will be matched against the station name in the setup file. The name VLBA will be a default for all VLBA stations.
PRIOrity
A ranking with low values prefered. This allows preference of one setup over another if both match the required frequencies. For example, the narrow band 50 cm receiver would be chosen over the wide band one for narrow band observations despite the fact that both would match the requested frequencies.
NAME
A name for the frequency group. It is used in listing and error notes to help the user find the right one. Up to 12 characters long. Any string ok.
NOTE
A comment about the setup that will go to various listings. It is wise to note any limitations here that might not be obvious to a user. Up to 80 characters.
IFNAME
The name of the IF for up to 8 IF descriptions (eg. A, B, C, D). There are a larger number than there are phsical IFs to allow description of such systems as the VLBA 50/90 cm system where there are more than one signal in each IF.

For antennas in the EVN that have VLBA(4) DARs, the codes in use are usually A and C (LCP and RCP). For MkIV antennas there are two IF distributors that can one can choose to connect to either IF channel. Each distributor is connected to a fixed subset of the BBC’s, either the odds or the evens. The normal situation has IF 1N on LCP and 2N on RCP, but alternate channels 1A or 2A can be connected if more than the first 7 BBC’s need to be set to a single polarization.

For the DBBC, IFNAME contains two characters. The first (A-D) gives the conditioning module to be used, the second (1-4) determines which of the switchable inputs on that conditioning module is to be selected. The signal available on each input depends on the local station wiring, so careful catalogue maintenance is required.

ALTIFN
An alternate IF name for this frequency setup. For the Mark IV systems, the odd BBC’s are attached to IF’s 1N and 1A. The even BBC’s are attached to 2N and 2A. Generally the same signal is put on 1N and 2A while another (other polarization) is put on 2N and 1A. When assigning IF names using frequency table information, sched will pick IFNAME or ALTIFN depending on whether the BBC is even or odd and on the first digit of the names.
RF1
The low edge of the RF frequency range covered by each IF. SCHED will try to find the group with all the channels best centered in the IF. However, some channels will allowed to be outside the range if necessary, as is common on the VLA.
RF2
The high edge of the RF frequency range covered by each IF.

For Mark IV systems, the frequency ranges in the frequency catalog are calculated with the constraint that the complete range can be obtained with the station preferred patching, i.e. with consistently using high or low output on the IF distributor. More frequency coverage can be obtained with detailed knowledge and requires a manual setup.

CH1RF1
The lowest RF frequency for channel 1. If non-zero, channel 1 will be required to fall in the range specified by CH1RF1 and CH1RF2. This is mainly to be sure that the right filter is used at 2cm on the VLBA.
CH1RF2
The highest frequency for channel 1. See CH1RF1
LO1
The FIRSTLO for each IF channel.
FE
The FE (receiver specification) for each channel. Use omit for unused channels.
POL
The polarization of the channel (RCP or LCP).
SYN
The SYNTH setting for each of the three front end synthesizers on the VLBA.
DUALX
Use the wideband scheme at 4 cm on the VLBA. See the setup parameter DUALX.
LCP50CM
Setting for the 50 cm filter. See setup file parameter LCP50CM
RCP50CM
Setting for the 50 cm filter. See setup file parameter RCP50CM
CHNSTA
Only use this IF if CHNSTA matches the station name. This allows the same groups to be used for VLA1 and VLA27, but to differ in the IFNAME. Options are the station name or BOTH. This facility has been disabled and may be removed. It has been made obsolete by the new digital patch panel at the VLA and the effort by SCHED to determine which IF’s are to be used for the each setup depending on the specified modes in the schedule. Modes VA, VR and VL require different IF restrictions.

The following are OBSOLETE VLA parameters that should not be used.

VLABAND
The VLA frequency band. See setup file parameter VLABAND
VLABW
The VLA bandwidth codes.
VLAFEAB
The VLA first LO.
VLAFECD
The other VLA first LO.
VLAIF
The VLA gain file name.
VLAROT
The VLA ROT file name.
VLASYNA
The VLA AC F6 setting.
VLASYNB
The VLA BD F6 setting.
FEFILTER
The VLA BD F6 setting.

3.6 Setup Files

Setup files are used to provide station-specific input parameters. Most are for the VLBA, which requires complete configuration information be present in each VLBA control file, and the VLA, which requires information for the frequency setup. For each scan in a schedule, the setup file is specified with SETUP. Once specified, it need not be given again unless it changes. Several setup files may be used in a schedule — usually for switching between frequency bands.

SCHED will not run without a setup file specified for each scan.

Setup files can be imbedded in the main program input, much like source and station catalogs. The group of inputs immediately before the setup file should contain the parameter SETINIT with an argument that gives this “setup file” (which may contain more than one group of stations) a name. This procedure may be used multiple times to specify several “setup files”. In the main schedule, the name given the imbedded file can be used as the argument to SETUP as if it were an external file.

The setup files can be used to control many aspects of the hardware setup at the stations. Mostly it is used to set frequencies and recording modes, but it also has pulse cal detection, pointing, and a number of other items. Most parameters can be left unspecified and SCHED, with the help of the frequency catalog, will find reasonable defaults. See the discussions of individual parameters for details. A reasonable minimum set would be: NCHAN, BBFILTER, BITS, POL (can be DUAL), and either BAND or FREQREF (and FREQOFF. Some users may wish to specify more information, for example BBC, NETSIDE, and FORMAT and perhaps many others rather than taking the defaults.

Each setup file can consist of several setup groups separated by “/”. Each group applies to the stations listed. This allows some parameters, such as FIRSTLO, to be station specific. However, if no station specific values are included, stations may be lumped together into a single group even though SCHED will have to separate them before using other information to set the station dependent parameters. The ultimate case of this is to have just one setup group and not specify any stations. This is possible if only generic parameters are given. SCHED will figure out what stations are needed and establish the necessary setup information.

If you don’t take the defaults, SCHED will check your setup against the information it has internally and in the frequency catalog. If your setup does not match one in the frequency catalog in terms of the setup of the IF’s, SCHED will complain, but not stop. If the complaint is about a VLBA setup, you are probably using a poor set of synthesizer settings or have some other such problem because the frequency catalog contains an essentially complete list of reasonable setups. Please be aware that there are filters in the LO and IF signal paths of the VLBA that many users do not know about. If your setup is not in the frequency catalog, you may simply have specified the wrong IF or synthesizer or you may be trying to use a signal outside of the band of some filter. For other stations, the frequency catalog is not so complete. If SCHED complains, double check your parameters to be sure they are right. In such cases, it is best to email your setup to Craig Walker (cwalker@nrao.edu) for further checking.

If only generic parameters such as those above are specified, multiple stations can be specified for a setup group. SCHED will actually take those multiple stations and create multiple setup groups before filling in the defaults, many of which will be station dependent.

3.6.1 Standard Setup Files

Over 200 standard setup files have been created, covering many of the normal modes of observing. They are available at the same place as the code for SCHED in a “setups” subdirectory. Users may opt to use these standard setups. However, now that BAND is available, it will make more sense for most users to make their own setups, imbedded in the SCHED input file. See the example egvlba.key for a template. The only parameters required in such a setup are BAND, NCHAN, BBFILTER, BITS, and POL. You need to know all of those just to pick the standard setup file to use so why not make your own? In fact, as users get accustomed to doing this, many of the standard setups may be dropped. This file has not been updated from MARK5A to MARK5C.

There are cases, however, when use of the standard files is recommended. These especially include precisely defined, and somewhat complex cases like the Mark III standard modes (although MarkIII went the way of the dinosaur long ago. Also, if none of the standard files matches the exact needs of a project, there is likely to be one that is close and can be modified as required. This is generally safer than creating a setup file from scratch because it will be clear what parameters are required.

The standard setup files take advantage of the defaulting ability of SCHED. If you are interested in what most of the setup parameters will actually be set to, the best way to do this is to run a simple dummy schedule that uses the setup and look at the details reported in the summary file. A simple file like the simple example given earlier should do (with OBSTYPE set to VLBI), although cover and correlator information will be required.

Standard setup files are named according to the following conventions:

v” files:
These are setup files for VLBI observations using VLBA recording formats. The VLBA system is very flexible so there are large numbers of options. There is much more information in the name which might be best described with an example. The file v6cm-128-4-2-L.set is for 6 cm observations in VLBA format. The first number after a “-” gives the total bit rate in Mbits/s which is 128 in this case. The next number is the number of channels (4). The last number is the number of bits per sample (2). If the file only uses one polarization, there will be an “L” or an “R” at the end. If the file uses upper and lower sidebands where all upper sidebands could be used on the VLBA, there will be a “UL” appended. These files can be used when observing with sites such as Effelsberg which have a limited number of BBCs. All setup files, by convention, end in “.set”. Note that one can deduce the bandwidth and sample rate from the above information assuming Nyquist sampling. With 128 Mbits/s and 4 channels, the channel bit rate must be 32 Mbits/s. With 2 bits per channel, this means that the sample rate is 16 Msamples/s. Nyquist sampling implies 8 MHz bandwidth per channel, which, with 4 channels, gives 32 MHz overall bandwidth.
m3” files:
These are setup files for Mark III observations. SCHED only supports Mark III observing for systems with VLBA control computers and data acquisition systems. These include the VLBA, the VLA, Green Bank, and, optionally, Effelsberg. An example file would be m3e18cmd.set. This means Mark III, mode E (4 passes per head position), 18 cm observing wavelength, double speed. Here, double speed means recording at 8 Mbits/s per track. With Mark III, there is a one-to-one correspondence between tracks and channels and there are a total of 28 possible tracks. Also, all sampling is in one bit mode. Mode E uses 7 tracks (channels) at a time so this setup specifies a total bit rate of (7 * 8) = 56 Mbits/s and, with Nyquist sampling, 28 MHz total bandwidth.
vla” files:
These are setup files for VLA-only observations. The don’t specify any tape related information.
pt” files:
These are setup files for VLBA pointing and antenna temperature measurements.
pc” files:
These are setup files for VLBA pulse cal tests.
nug” files:
These are setup files for Mark II observations. The standard “nug” files are not being maintained any more and may will not have the stations in them that are doing Mark II. They will need to be modified if anyone uses them. If they are, please send examples to cwalker@nrao.edu so new standards can be established. Mark II is no longer available on most antennas, including all that are operated by NRAO.

3.6.2 Examples of Setup Files

The standard setup files described above (Section 3.6.1) can be used as examples. However a few of them are shown here to show what they are like to someone who does not have easy access to the machine readable files.

The first example is of a minimal setup file of a sort that might be imbedded in a SCHED input file. It includes the lines needed for that imbedding. This specifies a 4 channel, 8 MHz/channel, dual polarization, 2 bit per sample mode (sometimes called 128-4-2 — 128 is the total number of bits per second) for observations near 15 GHz. It is invoked in the schedule by including “setup=egvlba.2cm” among the inputs for a scan. This is all many users will need.

setini = egvlba.2cm /  
  band=’2cm’  nchan=4  bbfilt=8.0  pol=DUAL  bits=2 /  
endset /

This example is for a Mark III mode B observation. This shows a number of items being specified that do not actually need to be specified since the defaults are reasonable. In particular, these are the track assignments and the pulse cal extractor assignments. The example just shows how one might specify all of these items if desired. Please start with the standard m3b6cm.set, rather than this, for any real observations.

This example is definitely out of date in detail since the Mark III tape recording system was abandoned long ago. But is shows what can be done in terms of a detailed setup. Someday, it should be updated to a currently used system.

 --------------------------------------------------------------------  
 EXAMPLE:   Mark~III observations, Mode B (with extra inputs)  
 --------------------------------------------------------------------  
! m3b6cm.set  
!  Tape length  Density  Tape speed  Time/pass  
!     17600      High      80.0         44:00  
!      8800      Low      135.0         13.02  
nchan = 14  samprate = 4.0  bits = 1  bbfilter = 2.0  !   56 Mbps  
tpmode = 2  format = MARKIII  
bbc      = 1,  1,  2,  2,  3,  3,  4,  4,  5,  5,  6,  6,  7,  7  
netside  = L,  U,  L,  U,  L,  U,  L,  U,  L,  U,  L,  U,  L,  U  
ifchan  = L,L,L,L,L,L,L, L,L,L,L,L,L,L  
freqoff = -16, -16, -12, -12, -8, -8, -4, -4, 0, 0, 4, 4, 8, 8  
track1=4,18,6,20,8,22,10,24,12,26,14,28,16,30  
track2=5,19,7,21,9,23,11,25,13,27,15,29,17,31  
pcalxb1  =  S1,  S2,  S3,  S4,  S5,  S6,  S7,  S8,  
            S9, S10, S11, S12, S13, S14,  S1,  S2  
pcalxfr1 = 990,  10, 990,  10, 990,  10, 990,  10,  
           990,  10, 990,  10, 990,  10,1990, 1010  
!    Radio Astronomy allocation: 4990-5000  
!    Radio Astnomomy footnote:   4950-4990  
!    VLA 50MHz 4960.1 to 5010.1 with VC mode.  
!        VLA 6cm receiver falling off at high end.  
station  = VLBA  
freqref  = 4990.99  !  Mark II network standard.  
fe(1)    = ’6cm’   fe(3) =  ’6cm’  
synth(2) = 4.1  
firstlo  = 4100.00    rchan = A  lchan = C  
   /  
station  = VLA27  
vlaband  = VC     vlabw = ’0000’  
firstlo  = 4360.10    rchan = A  lchan = C  
   /  
station  = VLA1  
fe(2) = ’6cm’  fe(4) = ’6cm’  
rchan    = B  lchan = D  
   /  
station  = GB_VLBA  
fe(1)    = ’6cm’   fe(3) =  ’6cm’  
firstlo  = 4260.0   rchan = A  lchan = C  
   /  
station  = EB_VLBA  
firstlo  = 4100.0   rchan = A  lchan = C    /

This example shows a setup file for dual frequency, wide spanned bandwidth, geodetic style observations. Note that the firstlo has to be specified separately for each channel because it varies.

! Standard setup file: vgeo-256-8-2.set  
!     (Produced by MAKESETUP)  
!  For dual frequency, single polarization, 13cm/4cm observations.  
!  Changed to use RDV frequencies (but ending in .49) 27 Feb 2002  RCW.  
!  Changed again to follow RDV away from satellite radio  29Jul2004 RCW.  
!  Move to offset frequency of 0.75 to conform to the combination of  
!  frequency between the DDC and the legacy systems.  Jan. 10, 2014.  RCW.  
!  RDV32 uses: 2225.99, 2255.99, 2345.99, 2365.99  
!              8405.99, 8475.99, 8790.99, 8895.99  
!  RDV45 uses: 2232.99, 2262.99, 2352.99, 2272.99 and same X as above.  
! ***  Geodesy reference frequecies ***  
!        Space Research (eg DSN) allocation: 2290-2300  
!        Space Research (eg DSN) allocation: 8400-8450  
!        Satellite radio 2320-2345.  
!      256 Mbps  64 MHz  
  nchan    = 8  
  bits     = 2  
  bbfilter = 8.0  
  freqref  =   2232.75,  2232.75,  2232.75,  2232.75,  8405.75,  8405.75,  
               8405.75,  8405.75  
  freqoff  =  0.0, 30.0, 120.0, 140.0, 0.0, 70.0, 385.0, 490.0  
  netside  =  U, U, U, U, U, U, U, U  
  pol      = rcp  
  /

3.6.3 Summary List of Setup File Parameters

A list of the setup parameters is given below, followed by detailed information on each setup paramater in Section 3.6.4. All of the parameters revert to the previous value if not specified for a station. This allows most to be specified only once per setup file. Some of the more difficult parameters, such as track assignments and pulse cal configurations have defaults in SCHED that should nearly always be used. There needs to be a separate group for each station, but after the first, the group may only contain the station name. The generic station “VLBA” can be used for all VLBA stations. If it is desired to specify one VLBA station differently from the the rest, that specific station (eg “VLBA_PT”) should be given before the generic “VLBA” station. All parameters can have different values for different stations.

Note that the VLBA uses the concept of baseband channels. Many of the parameters take an array of arguments, one for each baseband channel. The corresponding elements of the arrays specify the required information for the baseband channel, such as the BBC from which the signal will come, the VLBA IF that BBC is attched to, the bandwidth of the BBC, and the frequency of the BBC. There is nothing to prevent more than one baseband channel from being assigned to one BBC/sideband. In such cases, care should be taken to insure that the same frequency, bandwidth, and input VLBA IF are assigned for each such baseband channel. If this is not done, the on-line system can get confused about what signal is in each baseband channel.

 

AZCOLIM:  Collimation offset in azimuth.

 

BAND:     Specify the frequencies generically.

 

BARREL:   Control barrel roll mode.

 

BBFILTER: BBC bandwidth for each baseband channel.

 

BBC:      BBC assigned to each baseband channel.

 

BBSYN:    BBC frequency setting for each baseband channel.

 

BBSYN2:   Second set of BBC frequencies for frequency switching.

 

BITS:     Number of bits per sample.

 

DBE:      The personality to use in a digital backend.

 

DUALX:    Mode allowing more than 500 MHz at X band.

 

ELCOLIM:  Collimation offset in elevation.

 

FE:       Receivers to be used.

 

FIRMFILE: A firmware file name to use - VLBA testers only!

 

FIRSTLO:  Sum of all LOs except the one set if FREQ used.

 

FORMAT:   Recording format to use — (VLBA1:2 etc.

 

FREQOFF:  Value to add to FREQREF for each baseband channel to get LO sum.

 

FREQREF:  LO sum is FREQREF+FREQOFF. Alternative to BBSYN.

 

FRSWITCH: Specifies frequency switching.

 

IFCHAN:   IF channel to BBC for each baseband channel.

 

IFDIST:   Attenuation of and input to IF Distributers.

 

LCHAN:    IFCHAN to use if IFCHAN=L (LCP).

 

LEVEL:    Attenuator setting for BBCs.

 

LOGGING:  Type of logging to be done.

 

LCP50CM:  Controls narrow band filter at 50 cm for LCP.

 

M4PATCH:  Controls which MarkIV patching to use.

 

MODETEST: Allow use of features still under development

 

NCHAN:    Number of baseband channels.

 

NETSIDE:  Net sideband of baseband channel.

 

NOISE:    Noise diode switching mode.

 

NOISEFRQ:    Noise diode switching frequency (VLA or VLBA).

 

PERIOD:   Averaging time in the BBCs.

 

PCAL:     Mode for pulse cal generator.

 

PCALFR1:  Pulse cal frequencies to be detected by detector ch1.

 

PCALFR1:  Pulse cal frequencies to be detected by detector ch2.

 

PCALXB1:  Bit and channel assignment of ch1 of a pcal detector.

 

PCALXB2:  Bit and channel assignment of ch2 of a pcal detector.

 

POL:      The polarization of each channel.

 

PTINCR:   Step size for pointing patterns.

 

PTOFF:    Off source distance for pointing patterns.

 

RCHAN:    IFCHAN to use if IFCHAN=R (RCP).

 

RCP50CM:  Controls narrow band filter at 50 cm for RCP.

 

SAMPRATE: Sample rate.

 

SIDEBAND: BBC sideband for each baseband channel.

 

STATION:  Station name.

 

STRING1:  80 character string to pass to VLBA file.

 

STRING2:  Another string.      For any parameters

 

STRING3:  Another string.      not understood

 

STRING4:  Another string.      by SCHED.

 

SWTCHDUR: Duration of the scans in a frequency switching loop.

 

SYNTH:    2-16 GHz synthesizer settings.

 

TPMODE:   Number of passes per index position.

 

TPSPEED:  Speed of the recorder in inches per second (obsolete).

 

TPSPEEDH:  Tape speed in inches per second at high density (obsolete).

 

TPSPEEDL:  Tape speed in inches per second at low density (obsolete).

 

TRACK1:   Tape or Mark5A tracks for pass 1 at an index position.

 

TRACK2:   Tape tracks for pass 2 (obsolete).

 

TRACK3:   Tape tracks for pass 3 (obsolete).

 

TRACK4:   Tape tracks for pass 4 (obsolete).

 

TRACK5:   Tape tracks for pass 5 (obsolete).

 

TRACK6:   Tape tracks for pass 6 (obsolete).

 

TRACK7:   Tape tracks for pass 7 (obsolete).

 

TRACK8:   Tape tracks for pass 8 (obsolete).

3.6.4 Details of Setup File Parameters

AZCOLIM

AZCOLIM sets the azimuth collimation offset to add to the nominal one used by the VLBA on-line computers for pointing. Usually this will be 0.0. This allows the pointing for a VLBA antenna to be adjusted.

Argument: A pointing offset in arc minutes.

Options: Any real number.

Default: 0.0

Usage: Defaults to previous station.

Example: AZCOLIM=1.2

BAND

BAND provides a simple way of requesting an observing frequency. SCHED has an internal table of standard center frequencies that can be called upon with BAND. If BAND is specified, and FREQREF is not, SCHED will get the observing center frequency from its internal table and will calculate, based on the NCHAN, BBFILTER and POL parameters, the actual channel frequencies to use to center the observations at the desired frequency.

The bands and centerfrequencies are in the table below. When a bandwidth is not zero, that center frequency is used if the observation total bandwidth is the given amount. This allows the center to shift with increasing bandwidth, which is especially useful at 21 cm where the radio astronomy band is near the edge of the tuning range for the preferred IF at the VLBA.

----------------------------------------------  
        SCHED STANDARD OBSERVING BANDS  
----------------------------------------------  
                   Center  
      BAND        Frequency(1)   Bandwidth  
     ’90cm’         330.49          0.0  
     ’50cm’         610.98          0.0  
     ’21cm’        1465.49        128.0  
     ’21cm’        1435.49         64.0  
     ’21cm’        1416.49          0.0  
     ’18cm’        1658.49          0.0  (2)  
     ’18cm’        1653.99          0.0  (3)  
     ’13cm’        2295.49          0.0  
      ’6cm’        4990.49          0.0  
      ’4cm’        8415.49          0.0  
      ’2cm’       15285.49          0.0  
      ’1cm’       22235.49          0.0  
     ’24ghz’      23800.49          0.0  
      ’7mm’       43135.49          0.0  
       ’sx’   2295.49 and 8415.49   0.0  
----------------------------------------------  
1. Note, these are subject to change as the choices  
are discussed with the community.  
2. Most 18 cm observing.  
3. For 32 MHz wide observations involving Jodrell, but not the  
phased VLA.  Avoids RFI at Jodrell.  But must be higher to fit  
in the VLA IF’s.

Specifying the BAND works well when most setup file parameters are defaulted. But if the user insists on specifying many of the other parameters, such as IFCHAN, BBC etc, in non-standard ways, the program may not do the right thing. It is likely that this will generate an error when the setups are checked.

Argument: A string of up to 5 characters.

Options: One of the options listed above.

Default: Blank, which means the frequencies must be specified elsewhere

Usage: Defaults to previous station.

Example: BAND=’2cm’

BARREL

Barrel roll is not used on the disk based system so can be ignored in essentially all cases.

BARREL sets the mode of the barrel roll. The barrel roll is designed to protect data against bad recording tracks. Within each head group of 8 tracks, or in some modes, within a pair of head groups, the data for each “track” is actually recorded first on it’s assigned track, then the next frame (20,000 data bits) is recorded on the next track, and the next frame on the next track and so forth. After 8 or 16 frames, depending on mode, the track is back on it’s original assigned head. With this happening, if a recorder track is bad, some of all channels in the roll group are lost, but no channel is lost completely. Thus there is just a drop in sensitivity rather than a distortion of the information being measured. Very nearly all users should take the default of roll_auto. The options for BARREL are:

Barrel roll should be ok for PCFS systems (VEX files). In Dec 2000 the definition of barrel rolling has been updated to reflect the discovery that the current (VLBA) practice is time reversed with respect to the documentation.

Barrel roll is turned off for disk systems.

roll_off
turns off the barrel roll.
roll_8
rolls within one group of 8 heads.
roll_16
rolls within two groups of 8 heads each.
roll_auto
tells the on-line system to pick the best roll it can do.

One case where the user may need to set the roll is when the data will be correlated with 2048 point FFT’s (1024 point output spectra). This cannot be done with a 16 track roll and so one of the lesser rolls should be forced.

Argument: A string of up to 9 characters.

Options: One of the 4 options listed above.

Default: roll_auto

Usage: Defaults to previous station.

Example: BARREL=roll_8

BBFILTER

BBFILTER sets the baseband channel bandwidth. There is one value for each baseband channel. Any that are not specified will be set equal to the first so in the usual case that all channels have the same bandwidth, only one needs to be set.

For the RDBE systems with the PFB personality (DBE = RDBE_PFB), the bandwidth must be 32 MHz. There are no options. For the DDC personality (DBE = RDBE_DDC), the baseband channel bandwidth can be anywhere between 1 and 128 MHz in factor of 2 steps. For the DBBC, the options are the factors of 2 between 1 and 16 MHz, with additional options at 32 and 512 MHz to be enabled in the future.

For the original VLBA system and for MarkIV, the value must be a multiple of 2 times 0.0625 MHz up to a maximum of 16 MHz. Up to 16 values can be accepted. If two or more baseband channels are assigned to the same BBC/sideband, they should have the same BBFILTER assigned. If not the last will probably be used.

If not specified, one half of the SAMPRATE will be used for all channels, if SAMPRATE was specified.

For MkIV DARs in the EVN the 1 MHz, 250 kHz and 62.5 kHz filters are only available as plug-ins and should be avoided if possible. Although the 500kHz and 125kHz filters are standard they are generally only available on the USB of the first few BBCs. Most stations have 4, and are required to obtain up to 6.

Argument: Up to one real number for each channel giving bandwidths in MHz.

Options: 0.0625, 0.125, 0.250, 0.5, 1.0, 2, 4, 8, 16, 32, 64, 512, depending on system.

Default: 0 - If one is specified, it will be used for all channels. If none are specified, half the sample rate will be used.

Usage: Defaults to revious station.

Example: BBFILTER = 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2

which is same as BBFILTER = 2

BBC

BBC is used to specify the Base Band Converter (BBC) to which each baseband channel is assigned. A value can be given for every channel. If any or all values are missing, SCHED will try to set to reasonable default values for the digital backends and VLBA and MKIV format observations. This is the option most users should take.

Note that BBC assignments are arbitrary for the RDBE and the old VLBA systems since all BBCs can see all input IFs. However, for Mark III and Mark IV systems and the current version of the DBBC, there are strong constraints. For Mark III/IV “astronomical patching”, which is the only one currently properly understood, the odd BBCs must be connected to IF1 (IFCHAN 1N or 1A where 1N is normally LCP and 1A is normally RCP). Even BBCs must be connected to IF2 (IFCHAN 2N or 2A, where 2N is normally RCP and 2A is normally LCP). Mark III/IV “geodetic patching” is more complicated and partially understood by SCHED. Essentially IF1 is connected to BBCs 1 to 8, and IF2 is connected to BBCs 9-14, though in some systems there is an IF3 available on BBCs 3 and 4 (this is actually an additional mixer on IF1 allowing access to a wider range of frequencies). The current version of the DBBC also has constraints on patching of BBCs to IF as described in the DBBCVER section of the manual.

Argument: Up to one integer per baseband channel.

Options: Integers between 1 and 8 make sense on the VLBA. Higher numbers make sense on some systems.

Default: 0

Usage: Defaults to previous station.

Example: BBC=1,1,2,2,3,3,4,4,5,5,6,6,7,7

BBSYN

BBSYN is used to set the frequency for the BBC or digital filter assigned to each baseband channel (subband channel in EVLA terminology). This number will be overridden if FREQ or DOPPLER is specified in the SCHED keyin file. Even if DOPPLER is specified, this value serves as the default for continuum sources for which no velocity or DOPSRC is specified. All baseband channels assigned to the same physical BBC should be assigned the same frequency. This only applies to hardware for which the BBCs can provide upper and lower sidebands. For the digital backends where the “BBC” is just part of the FPGA firmware, there will only be one baseband channel per BBC. When a BBC can provide more than one channel and different frequencies are given for such paired channels, the last specified frequency will probably be used and the monitor system will get confused about what signals are present. Actually, first SCHED will complain. Please see FREQREF for a discussion of required parameters.

For MkIV all BBCs at a given station should fall in the range 100 - 220 (the “Low patch”) or 220 - 500 the “High patch”).

For the VLBA legacy DAR and MkIV systems, the baseband frequency must be set on even 10 kHz frequencies.

The future is with the digital backends - the RDBE for the VLBA and related systems and the DBBC system from Noto being deployed in Europe and elsewhere. There are also systems in other parts of the world but more information is needed before those can be described.

With the RDBE DDC personality, there are some IF frequencies to avoid. After sampling at 1024 GHz (the usable IF frequencies are between 512 and 1024 MHz), the firmware does a polyphase filter to narrow the bandwidth to match what the FPGA clock rate can handle (256 MHz in this case. A complex filter is used which allows output bandpasses of 256 MHz width. But the edge bands are centered at the sample rate and at half that so only half of each of those bands can be used. Thus the accessible IF is divided into 3 bands: 512-640 MHz, 640-896 MHz, and 896-1024 MHz. Baseband channels can be placed anywhere in any one of those 3 filter bands, but one should not attempt to cross the boundary between two. That won’t work and SCHED will issue a warning.

The DDC personality can provide 4 basebands per RDBE and there are two RDBE units at each station. Those basebands can have bandwidths of the factors of 2 between 1 and 128.0 MHz. Spectral zoom mode in the DiFX correlator can be used to obtain narrower bandwidths. The total output bit rate has a maximum of 2048 Mbps. The values of BBSYN can be set to any frequencies that are 1024 MHz (the sample rate) divided by powers of 2. The finest setting is 0.0596046 Hz. But any frequency that does not have an integer number of cycles in one second can cause big problems with carrying phase over various events like frequency switches. So the settings must be limited to multiples of 15.625 kHz — the smallest setting that has an integer number of cycles in a second. This can be looked at as N*125 kHz + 0, 15.625, 31.250, 46.875, 62.500, 78.125, 93.750, or 109.375 kHz. SCHED will not accept settings that are not multiples of 15.625 kHz. Projects working with stations with other systems constrained to multiples of 10 kHz should use frequencies that are multiples of 250 kHz. SCHED will warn of attempts to use finer settings. Note that any crd files to control the old system while the DDC is in use will have BBC frequencies rounded to the nearest 10 kHz because of hardware limitations in the legacy BBCs. That should be ok as data from the BBCs are most likely not going to be recorded.

The PFB personality of the RDBE, (DBE = RDBE_PFB) has rather rigid baseband frequency options. A polyphase filter divides the 512-1024 band into 17 baseband channels, 15 of which have 32 MHz bandwidth. The other 2 are half bands on the ends (actually full bands, but centered on the sample rate and half that). Those edge channels do not provide useful data, but often one is used when recording single polarization to reach the required 16 basebands. Each RDBE has 2 IF inputs and puts out 2048 Mbps (512 MHz total bandwidth with 2 bit samples and Nyquist sampling) in 16 total baseband channels. There is not yet any ability to vary the bit rate. The 16 channel can be chosen arbitrarly from all those produced from both IFs.

The allowed BBSYN frequencies for the PFB personality are 1040.0 1008.0, 976.0, 944.0, 912.0, 880.0, 848.0, 816.0, 784.0, 752.0, 720.0, 688.0, 656.0, 624.0, 592.0, and 560.0 and the bands must be lower sideband. The frequencies listed are at the top of the 32 MHz channel. The first is the one that will produce a corrupted baseband.

The DBBC system is more of a plug replacement for the MarkIV. The DBBC has a range of possible IF frequencies, but currently only 2 are supported (10-512 MHz and 512-1024 MHz). Up to 16 BBSYN frequencies can lie anywhere in the selected IF at a multiple of 10 kHz.

Argument: Up to 16 frequencies in MHz.

Options: Any multiple of 0.01 MHz from 500.0 to 999.99 MHz.

Default: 0 - should be specified.

Usage: Defaults to previous station.

Example: BBSYN=720.99,720.99,724.99,724.99

BBSYN2

If frequency switching is specified, BBSYN2 is the set of frequencies for the second scan of the switching loop. Frequency setting using FREQREF and any pcal defaults are not used for the second frequency set. BBSYN2 must be specified for this frequency set.

Frequency switching is not allowed when writing VEX files. Also, it is a little known and probably nearly unused option so it is not well tested and may well go away some day.

Argument: Up to 16 frequencies in MHz.

Options: Any multiple of 0.01 MHz from 500.0 to 999.99 MHz.

Default: 0 - should be specified if frequency switching is requested but not needed otherwise.

Usage: Defaults to previous station.

Example: BBSYN2=728.99,728.99,732.99,732.99

BITS

BITS sets the number of bits per sample for each baseband channel. If any channel is not specified, it will be set to the first. Since an experiment will typically use the same number of bits per sample for all channels, it is usually only necessary to specify one value.

If BITS is 2, the first magnitude bit is placed on assigned track plus 8 for FORMAT = VLBA1:4, on assigned track plus 4 for FORMAT = VLBA1:2, and on assigned track plus 2 for FORMAT = VLBA1:1.

Argument: An array of integers, one for each baseband channel.

Options: 1 or 2

Default: 1 for all baseband channels if none are set. Same as baseband channel 1 if one or more are set.

Usage: Defaults to previous station.

Example: BITS=1

DBE

DBE is used to specify the personality to use in a digital backend that is based on an FPGA. Such personalities can be changed quickly, so this parameter is not appropriate for the station catalog. However personality changes have not been integrated with the observing system yet so they will not be allowed within one key file. Use multiple key files if you must switch, and don’t do it often. The personality determines much about the capabilities of the hardware. In particular, it determines what baseband frequencies can be set.

The possible options are:

RDBE_PFB is the original polyphase filter personality developed by Haystack for the RDBE digital backend (DAR=RDBE in the station catalog). It is restricted to 16 baseband channels of 32 MHz bandwidth each, lower sideband, with frequencies of 1024-16-N*32 MHz, where N is an integer between 0 and 15. The initial version is restricted to N even and there are no choices. In that version, channels come in pairs, one on each input IF, which are usually polarization pairs. Switching is being added to allow general selection.
RDBE_DDC is the digital downconverter personality being developed for the RDBE digital backend at NRAO. It has a high degree of flexibility of tuning frequency and bandwidth. The restrictions will be given here once they are known in detail. For this personality, the input IF (512-1024 MHz) is split into three signals by a complex polyphase filter into three bands (512-640, 640-896, and 896-1024 MHz). Note that the central one is 256 MHz wide while the other two are 128 MHz wide. The few MHz around the transition between these bands should be avoided as signal will be degraded, and any one baseband can only access one side of such a “crossover” frequency. SCHED will warn of attempts use degraded frequencies (eventually). The RDBE_DDC can provide 4 baseband channels from each of the two input IFs. Those baseband channels can be as wide as 128 MHz so the full input bandwidth can be covered. See the wideband observing section for more information about tuning restrictions and about the use of dual RDBEs.
DBBC_PFB This is for the DBBC digital backend being built in Noto for the EVN. It is meant to have the flexibility of the old MarkIV and VLBA backends. Like the RDBE, it has PFB and DDC options. The PFB option is much like the RDBE equivalent and the two will be treated the same in SCHED until that proves to be incorrect.
DBBC_DDC This is the digital down converter option for the DBBC. Unlike the RDBE equivalent, it does not have crossover issues as the frequency conversion is done on the full bandwidth data stream. Each channel, or upper and lower sideband pair of channels, is derived in a separate converter. Basically it tries to duplicate the function of the legacy BBC/VC in a digital package with sampling before the filter. There are complicated restrictions on the IFs that can be assigned to each BBC as described in DBBC. These restrictions should be alleviated with future firmware upgrades.

DBE should not be specified for DAR’s other than the RDBE and DBBC. Note that it may be necessary to explicitly set DAR to ’ ’ (blank) if there are multiple segments to the setup file and an earlier one has it set to something else.

When the DAR is the RDBE, the output channels and all the input channel information given to SCHED are written to the VEX file. But the crd files that control the old VLBA hardware also has to be told something. SCHED does not have a separate set of variables for all those configuration parameters, so it just does something reasonable. It sets the number of channels to the maximum of the number requested and 8. It sets the frequencies and sidebands to match the RDBE requests. It sets the sample rate to the maximum of that requested and 32 Ms/s. It sets the channel bandwidth to the lesser of the request and 16 MHz. It only writes the first 4 pcal extraction requests (avoiding going into channel numbers that are too high).

Argument: A character string of up to 8 characters

Options: One of ’ ’, ’RDBE_PFB’, ’RDBE_DDC’, ’DBBC_PFB’ or ’DBBC_DDC’. It is not case sensitive

Default:RDBE_PFB’ for a station with the RDBE DAR, ’DBBC_PFB’ for a station with the DBBC DAR, and blank for anything else.

Usage: Defaults to previous segment. See note above about setting blank

Example: DBE=’RDBE_DDC’

DUALX

DUALX is a switch to turn on the mode where the B and D IFs are both assigned to RCP at 4 cm, but with separate first LOs. IF B uses SYNTH 1 while IF D uses SYNTH 3. This allows more than 500 MHz to be spanned instantaneously in this band and is used for geodetic and astrometric observations.

Argument: None.

Options: Do or do not specify.

Default: B is RCP, D is LCP and both use SYNTH 1.

Usage: Defaults to previous station.

Example: DUALX

ELCOLIM

ELCOLIM specifies the elevation collimation offset to be added to the one used by the VLBA on-line computers. It can be used to adjust the VLBA pointing.

Argument: A pointing offset in arc minutes.

Options: Any real number.

Default: 0.0

Usage: Defaults to previous station.

Example: ELCOLIM=1.2

FE

FE gives four front end specifications for VLBA antennas, one for each IF (A, B, C, and D). Note that the 2cm front end on the VLBA has 4 filters; the on-line system chooses which to use based on the frequency of baseband channel 1, with the dividing points for the filter choice are 12.9, 13.9, and 14.9 GHz. FE = omit may be specified to cause a channel not to be used.

FE can also be used for other stations, especially the VLA and any station that uses a VLBA backend. The 4 receiver names correspond to the first 4 IFs. SCHED can provide appropriate defaults for the VLA based on the frequency requests.

The front ends for the VLA and VLBA are listed here. The maximum ranges are given for the VLBA, which may be considerably greater than the good ranges, especially at 13cm.

Name (FE)      VLBA Range  VLBA IFs  VLA Range  
VLBA   VLA         GHz                 GHz  
4 m     4          ---        --   0.058-0.084  
90cm    P      0.302-0.352    BD    0.23-0.472  
50cm    -      0.588-0.633    BD       ---  
20cm    L       1.18-1.85     AC     1.0-2.03  
13cm    S       1.92-2.84     AC     2.0-4.0  
6cm     C        3.9-7.9     ACBD    4.0-8.0  
4cm     X        7.7-9.05     BD     8.0-12.0 (also called 3cm)  
2cm     Ku      11.8-15.6     BD    12.0-18.0  
1cm     K       20.5-25.3     --    18.0-26.5 (also called 1.3cm)  
 -      Ka         ---        BD    26.5-40.0  
7mm     Q       37.6-46.2     AC    40.0-50.0  
3mm     -       79.7-96.0     BD       ---  
13cm and 4cm can be observed together on the VLBA using all 4 IFs.

Argument: A character string containing one of the options.

Options: Band name for IF A, B, C, D in FE elements 1, 2, 3, 4. omit for an unused IF (that’s the default for unused IFs.).

Default: 0 - should be specified for the used IFs.

Usage: Defaults to previous station if none are specified. If any are specified, only the new values are used.

Example: FE(1)=’20cm’ FE(3)=’20cm’

FIRMFILE

If you are not involved in VLBA testing, you don’t want to know about this parameter!

FIRMFILE is a way to specify the file name of the version of the digital backend firmware that will be used for an observation. It was requested after excessive confusion was encountered during intensive testing. It will cause a comment with the file name to be inserted in the VEX file $TRACKS section.

Argument: A character string of up to 80 characters meant to be a file name.

Options: If you have to ask, don’t try to use this parameter

Default: Blank

Usage: Kept for each setup group specified for the setup file.

Example: firmfile = ’DDCxy7872203’

FIRSTLO

FIRSTLO gives the LO sum for each baseband channel for all mixes other then the one that will be set if FREQ or DOPPLER is specified. For most stations, this is for use by SCHED only; it is not written to the output file. However for stations that use VLBA control files, but are not proper VLBA stations, it will be written in a parameter that passes the information to the logging and correlator systems so that they can figure out the observing frequency. Please see FREQREF for a discussion of required parameters. If a value is not specified for a channel, it will be set to the first. Since most observations use the same firstlo for all channels, it is usually only necessary to specify one.

For the VLBA: For frequencies below 16 GHz this is just the front end synthesizer as specified by SYNTH. For 1 cm, it is the sum of synthesizers 2 and 3. For 7 mm, it is the sum of synthesizer 1 and 3 times synthesizer 3. For 4 mm, it is the sum of synthesizer 1 and 6 times synthesizer 3. At 90cm the value should be -500.0 MHz to make any frequency calculations come out right; that mix is an up-convert.

If FIRSTLO is not specified, SCHED will try to determine it from the frequency catalog. This should be the usual case.

Argument: An array of frequecies in MHz.

Options: Any valid LO sum.

Default: Will set based on the frequency catalog. If channel 1 is set and others are not, the others will be set equal to channel 1.

Usage: Defaults to previous station.

Example: FIRSTLO = 2400, 2400

FORMAT

FORMAT is used to specify the recording format. Note that it is couched in terms of tracks despite the switch to disks because the concept is still used in Mark5A and in Mark5A+ playback of Mark5B. Options are:

             - Set according to DAR/DBE type for first stage default.
     VDIF    - When DBE=RDBE_DDC
     MARK5B  - When DBE=RDBE_PFB or using DBBC
VLBA formats - VLBA legacy type systems:
     VLBA    - Let SCHED choose the fan out.
     VLBA1:1 - 1 bitstream on 1 tape track. VLBA format.
     VLBA1:2 - 1 bitstream on 2 tape tracks (fan out).
     VLBA1:4 - 1 bitstream on 4 tape tracks (fan out).
     VLBA2:1 - 2 bitstreams on 1 tape track (fan in).
     VLBA4:1 - 4 bitstreams on 1 tape track (fan in).
MKIV formats -Mark IV (and VLBA4) systems:
     MKIV    - Let SCHED choose the fan out.
     MKIV1:1 - 1 bitstream on 1 tape track. Mark IV format.
     MKIV1:2 - 1 bitstream on 2 tape tracks (fan out).
     MKIV1:4 - 1 bitstream on 4 tape tracks (fan out).
     MKIV2:1 - 2 bitstreams on 1 tape track (fan in).
     MKIV4:1 - 4 bitstreams on 1 tape track (fan in).
MARKIII format - Mark III and VLBA systems.
     MARKIII - Mark III tape format. No fan in or out.
S2 - Canadian S2 record systems.
     S2 - All S2 recordings.
Others:
     MARKII - No action. Use for Mark II and single dish.
     NONE - No tape to be used, as for pointing.

Note on track assignments: Track assignments are an easy thing to get wrong. SCHED will make track assignments automatically for some modes if they are not specified in the setup file. Most users should take advantage of this facility. Automatic track assignments will be made for MARKIII modes with 1 bit only, and for VLBA1:1, VLBA1:2, and VLBA1:4 modes with 1 or 2 bits. The barrel roll is on by default (can be controlled with BARREL) in VLBA modes and off in MARKIII mode. The roll is within 8 or 16 track groups, advancing one track for each frame.

The fan in modes, VLBA2:1 and VLBA4:1 were never implemented, so this paragraph is only retained for historical reasons. If using a fain in mode, give the same track assignment to 2 or 4 channels. In the fan in modes, if there are 2 bits per sample, the two bits will be put on the same track so there will be one channel per track for VLBA2:1 mode and two channels per track for VLBA4:1 mode.

For the fan out modes, VLBA1:2, VLBA1:4, MKIV1:2, and MKIV1:4, give the first track assignment for the baseband channel. Sequential formatter track assignments are used for the other tracks associated with that baseband channel. The resulting recorder track assignments are then given below:

VLBA1:2, MKIV1:2:
forward, track for 1st bit - 3 7 11 15 19 23 27 31
forward, track for 2nd bit - 5 9 13 17 21 25 29 33
reverse, track for 1st bit - 2 6 10 14 18 22 26 30
reverse, track for 2nd bit - 4 8 12 16 20 24 28 32
VLBA1:4, MKIV1:4:
forward, track for 1st bit - 3 11 19 27
forward, track for 2nd bit - 5 13 21 29
forward, track for 3rd bit - 7 15 23 31
forward, track for 4th bit - 9 17 25 33
reverse, track for 1st bit - 2 10 18 26
reverse, track for 2nd bit - 4 12 20 28
reverse, track for 3rd bit - 6 14 22 30
reverse, track for 4th bit - 8 16 24 32

Note that MkIII modes are obsolete.

Format NONE is used for VLBA testing, such as single dish pointing. When specified for VLBA data, the on-line system does not touch the formatter. This includes not readjusting the pcal detection. Format NONE will mainly be used by VLBA staff for testing and in high frequency projects that do reference pointing. If the reference pointing scan uses this format, no formatter reconfigures are done which can prevent the significant data loss that can happen at reconfigures.

Note that it is not necessary to specify FORMAT. FORMAT will be set equal to DAR in the station catalog.. Stations with DAR = VLBA4 will write Mark IV format on the tape. When the default format is taken, the barrel roll is turned off for formats other than VLBA.

Argument: Text string of up to 8 characters.

Options: See above text. Anything else will cause SCHED to abort.

Default: DAR from station catalog.

Usage: Defaults to previous station.

Example: FORMAT=MARKIII

FREQOFF

FREQOFF gives the increment to the LO sum for the baseband channel in MHz. This will only be used if FREQREF is used. The LO sum for baseband channel i will be set to FREQREF(i) plus FREQOFF(i), and BBSYN will be set to the absolute value of the difference between the LO sum and FIRSTLO. Please see FREQREF for a discussion of required parameters.

Argument: Up to 16 frequencies in MHz.

Options: Any valid frequency offset that gives a BBSYN in the allowed range.

Default: 0.0 - no offset.

Usage: Defaults to previous station.

Example: FREQOFF=-6.,-4.,-2.,0.,2.,4.,6.

FREQREF

FREQREF is the LO sum to use for the baseband channel in MHz. FREQOFF will be added to it. The LO sum is the sum of the FIRSTLO plus or minus, depending on sideband, the BBC synthesizer setting BBSYN. A FREQ specification in the SCHED keyin file will override FREQREF plus FREQOFF, as long as the BBC settings stay within range and there are no sideband changes.

To set pulse cals properly and to deal with non-VLBA stations correctly, it is best to know all of the LO sum, the first LO, and the BBC settings, along with all of the required sidebands. Strictly speaking, valid VLBA schedules can be written without knowing all these, but SCHED can be made significantly simpler and more reliable if all this information is required. Not all of these values need to be specified since they are related. There are four possible complete combinations, and if more values are specified than necessary then a consistency check will be done. These complete combinations are:

1. FREQREF plus FREQOFF, FIRSTLO, NETSIDE
2. FREQREF plus FREQOFF, FIRSTLO, SIDEBAND
3. BBSYN, SIDEBAND, NETSIDE, FREQREF plus FREQOFF
4. BBSYN, SIDEBAND, NETSIDE, FIRSTLO

Argument: Up to 16 frequencies in MHz.

Options: Any valid frequency.

Default: 0.0 for FREQREF(1) which means don’t use it. For baseband channels 2 and higher, will be set to FREQREF(1).

Usage: Defaults to previous station.

Example: FREQREF = 1662.49

FRSWITCH

FRSWITCH is a switch that turns on frequency switching. If specified, a second group of synthesizer settings should be given in BBSYN2. This is used for VLBA files only. In fact, the program will die if frequency switching is attempted when a VEX output file is required.

In general, frequency switching is probably better handled with a scan loop. The FRSWSITCH option is not used often, if ever, and should only be used with care.

Argument: None.

Options: Do or don’t specify it.

Default: Not set.

Usage: Defaults to previous station.

Example: FRSWITCH

IFCHAN

IFCHAN is used to specify the IF channel attached to each baseband channel for VLBA observations using VLBA data aquisition systems. For the VLBA, it should be A or C for 20, 13, or 6cm. For 90, 50, 4, 3, 2, or 1.3cm, it should be B or D. A and B are RCP; C and D are LCP. If DUALX is specified, both B and D are RCP. The new 4-8 GHz system (still called 6cm) can put out signals on all 4 IFs in 2 polarization pairs. The BBCs of the legacy backend can access any of the 4 IFs. An RDBE can only access 2 (any 2), so the 2 RDBE option is needed to access all 4.

As an alternative to explicit specification of the IF, R or L can be specified. Then if RCHAN and LCHAN are specified in the setup files, IFCHAN=’R’ will be replaced with RCHAN and IFCHAN=’L’ will be replaced with LCHAN. If a bad RCHAN or LCHAN value is specified, SCHED will then complain about a bad IFCHAN specification.

1N, 1A, 2N, 2A are allowed values for MkIV telescopes. See BBC and the frequency catalog parameter IFNAME for more details.

A[1-4], B[1-4], C[1-4] and D[1-4] are all possible values for the DBBC. The letter gives the conditioning module (A-D) to use, and the number gives the input (1-4) on that conditioning module to select. See the DBBC section of the manual for more details.

The “geodetic” wired VLBA systems (all not controlled by VLBA software) have restrictions on their IF assignments because the IF distributors only provide enough signals from each IF to feed 8 BBCs while these systems typically have 14 BBCs. The systems are wired so that BBCs 1 and 2 can see all 4 IFs, BBCs 3-8 can see A and C, and BBCs 9-14 can see B and D. In addition, the racks can be switched so that they provide one bit samples from all 14 BBCs or 2 bit samples from the first 8. SCHED understands all this and should give the right default assignments. This is one of many reasons why, as noted below, it is best to let SCHED set many parameters including IFCHAN.

It should now be normal not to specify IFCHAN. SCHED will use the requested POL and the frequency catalog to determine the correct IFCHAN. If IFCHAN is specified as “R” or “L”, and RCHAN, LCHAN, and POL are not specified, SCHED will get the obvious polarization channels, although use of POL is recommended.

As of early 2013, the VLA can provide 4 output basebands to the recording system. Each is expected to come from a different IF so they should be assigned to A, and C for RCP and B and D for LCP. Eventually there will probably be an increase in the number and more than one channel will use the same IF.

Argument: An array of up to 16 characters of length 2.

Options: A, B, C, D, R, L, ’1N’, ’1A’, ’2N’, or ’2A’ (quotes required on those that start with a number).

Default: Will determine from the frequency catalog.

Usage: Defaults to previous station.

Example: IFCHAN=A,C,A,C,A,C,A,C,A,C,A,C

IFDIST

IFDIST specifies the attenuation to apply in the IF distributers. There is one value for each of the four IFs. This is only used to attenuate the signals from solar observations or to select alternate inputs, for example, for mm observations at VLBA sites with links to other antennas.

This currently (Oct. 2001) is not implemented for VEX files.

Argument: A character string of up to 3 characters. The integers 0 and 20 are also acceptable.

Options: 0, 20, ’A’, ’20A’, or ’A20’ but nothing else. 0 - normal input, no attenuation. 20 - normal input, 20db attenuation. A - alternate input, no attenuation. 20A and A20 - alternate input, 20db attenuation.

Default: 0

Usage: Defaults to previous station.

Example: IFDIST=0,0,’A’,0

LCHAN and RCHAN

LCHAN specifies the IFCHAN to use if IFCHAN=’L’ as in LCP. RCHAN serves the same purpose for RCP. If an invalid argument is used, SCHED will complain that IFCHAN is bad. This allows IFCHAN to be specified by polarization which is more meaningful to the observer. It also makes it easier to deal with antennas, such as the VLA, that might have different IF assignments than the VLBA.

Argument: A single character.

Options: A, B, C, or D

Default: None. Must specify if IFCHAN=’L’.

Usage: Defaults to previous station.

Example: LCHAN=A RCHAN=C

LEVEL

LEVEL specifies the setting of the attenuators in the base band converters (BBCs). Values between -1 and 256 can be used. If -1 is set, the autoleveling will be activated. If 256 is set, the value from the previous scan will be used, thereby locking in an autolevel value for, for example, pointing. Any value in between sets a specific attenuation, but such values are rarely used. Only one value is accepted but SCHED writes that value out separately for each baseband channel.

This currently (Oct. 2001) has no effect on the VEX file.

Argument: An integer giving the level setting.

Options: -1 to 256. See above.

Default: -1

Usage: Defaults to previous station.

Example: LEVEL=-1

LOGGING

LOGGING specifies the type of logging to be done on the VLBA. STANDARD is appropriate for normal observations of almost any kind. POINTING is for pointing observations, although current pointing observations actually use STANDARD. NONE causes the system to do only the same background monitoring that is done when the antenna is idle. SPECIAL or a specific file name uses a special list of monitor points and logging intervals provided by the VLBA operators. If one of these special files is used, it is wise to put a comment in the experiment cover information that the special logging file is needed. Someone (PI or analyst) should add this to the operators questionnaire. STANDARD, NONE, and POINTING are not case sensitive. Any special file name must match in case the name of the file loaded at the sites. Contact the chief VLBA operator to get special files made.

One of the uses of this system is to allow monitoring of system temperatures at very short intervals. Monitoring at 5 second intervals is ok with the STANDARD logging. For 2 second points, a special file is available called dblog2.

This has no effect on the VEX file.

Argument: Character string - special file names are case sensitive.

Options: STANDARD, NONE, POINTING, or the name of a special logging file that the operators have put at the stations.

Default: STANDARD

Usage: Defaults to previous station.

Example: LOGGING = ’dblog2’

LCP50CM and RCP50CM

LCP50CM and RCP50CM controls the LCP and RCP narrow-band (609 to 613 MHz) filter in the 50cm system on the VLBA. BROAD means do not use the filter, while NARROW means use it. This band is in the UHF TV bands (channel 37) and at some sites the RFI without the filter is so bad that the system will saturate, even for the 90cm system (since the IF will saturate). The filter should be used if at all possible.

Argument: Character string.

Options: BROAD or NARROW

Default: NARROW

Usage: Defaults to previous station.

Example: LCP50CM = BROAD RCP50CM = BROAD

M4PATCH

M4PATCH allows specification of the patching at MarkIV stations. There are limited options so far - ASTRO and GEO1.

ASTRO is the default and has the odd numbered VCs on IF 1 (IFCHAN 1N and 1A) and even numbered VCs on IF 2 (IFCHAN 2N and 2A). Note that 1N and 2A are often connected to the same thing. Same for 2N and 1A. IF 3 is not used.

GEO1 is for a geodetic style patching. The pattern is:

        VCs 1-2    IF1 low  = 8180-8300 MHz  
         "  3-4    IF1 high = 8300-8580 MHz  
         "  5-8    IF3      = 8680-8980 or 8280-8580 MHz  
         "  9-10   IF2 low  = 2120-2240 MHz  
         "  11-14  IF2 high = 2240-2520 MHz

Argument: Character string of length up to 8.

Options: ’’ASTRO’’ or ’’GEO1’’

Default: ’’ASTRO’’

Usage: Defaults to previous station.

Example: M4PATCH = GEO1

MODETEST

MODETEST was first used to allow testing of recording modes that were not ready for public release. It is being adapted for use whenever there are features under development that should not be used by normal scientific users. Either the features are still under test, or have not been deployed to sufficient antennas to allow science use. For example, it will be used while the new VLBA synthesizers are being tested and deployed.

Argument: None.

Options:

Default: Defaults to false which means don’t allow unreleased features.

Usage: Defaults to previous station.

Example: MODETEST

NCHAN

NCHAN gives the number of baseband channels. A baseband channel is the smallest unit that was once an analog signal. One sideband from one BBC is a baseband channel. Nothing prevents the user from assigning several channels to the same BBC/sideband. In such cases, the data in the two channels will be identical.

Argument: An integer.

Options: Any integer between 1 and the maximum number of channels which on the VLBA is 16.

Default: 0 - it should be specified.

Usage: Defaults to previous station.

Example: NCHAN=14

NETSIDE

NETSIDE gives the net sideband. Usually to be used in conjunction with FREQREF and FIRSTLO. If SIDEBAND is not set to U or L, it will be set based on NETSIDE and the frequency settings. Please see FREQREF for a discussion of required parameters.

If only one value is specified, it is used for all channels.

Sched will attempt to make a default for NETSIDE if it is not specified. The default will depend on the number of channels in the setup file and the number of BBC’s available at the station. All upper sideband will be specified if possible. Upper/lower pairs will be specified otherwise (not in Mark III mode). This defaulting will not be attempted if SIDEBAND is specified (might generate conflict) or if FREQREF is absent (frequency might end up inconsistent with defaults).

Argument: An array of up to 16 single characters.

Options: U or L. Otherwise will not be used.

Default: 0 - defaulted or determined from other parameters. Any unspecified channels will be set the same as the first.

Usage: Defaults to previous station.

Example: NETSIDE=U,L,U,L,U,L,U,L

NOISE

NOISE is the specification for each IF of the switching mode of the noise cals on the VLBA. The usual for VLBI is ’low-s’ which means that the low noise cal, about 3 K, is switching continuously at 80 Hz for continuous system temperature measurements, while ’low-c’ means low continuous. ’high-s’ and ’high-c’ are the same requests for the high (solar) cals; beware that most receivers do not have solar cals.

This has no effect on the VEX file.

Argument: 4 character strings of up to 6 characters each, one for each IF.

Options: ’off’, ’low-s’, ’low-c’, ’high-s’, ’high-c’

Default: 0 - which is interpreted to mean ’low-s’

Usage: Defaults to previous station.

Example: NOISE=’low-s’,’low-s’,’low-s’,’low-s’

NOISEFRQ

This is not a useful parameter (2013) as the Pie Town link is not in operation. Someday it may be reactivated, although with different hardware.

NOISEFRQ is used to tell the system to use either the VLBA or VLA noise tube switching frequency. This is for VLBA antennas only and actually only applies to Pie Town for when the Pie Town-VLA link is working. Note that the VLA switching frequency is 9.6 Hz and the VLBA frequency is 80 Hz. This means, for example, that there will be 80 on and 80 off states per second on the VLBA.

This has no effect on the VEX file.

Argument: 1 character string of up to 4 characters.

Options: ’VLBA’, ’VLA’

Default: ’VLBA’

Usage: Defaults to previous station.

Example: NOISEFRQ=’VLA’

PERIOD

PERIOD gives the integration time for detected powers in the base band converters (BBCs). One value is accepted here although SCHED will write that value out separately for each baseband channel. It would be ideal to set this to 30 seconds or so, but this time is also used for the auto-leveling time constant so it should be significantly less, with values of 1 or 2 typical. A value of 0 implies do not integrate beyond the 1/80 sec cal cycle time.

Argument: An integer giving the integration time in seconds.

Options: Any integer 0 or greater.

Default: 1

Usage: Defaults to previous station.

Example: PERIOD=2

PCAL

PCAL sets the mode of the pulse cal generator on the VLBA. Note that this can also be controlled from the main schedule. Most setup files will set this to the 1 MHz setting. If it should be turned off, as for spectral line observations which might be confused by the presence of the tones, it is likely that the user will want it on for some scans (calibrators, for example) and off for others. In such cases, it is most convenient to control it from the main schedule.

This currently (Oct 2001) cannot be controlled by means of the VEX file. Most MkIV stations only support “1MHz” or “off”. Around the EVN, 1 MHz insertion is the default and switching it off is still a manual operation at most stations that must be brought to the attention of the local Friend of VLBI.

Argument: 4 characters - see options.

Options: - use default ’1MHz’. ’off’ - turn off pulse cal generator. ’1MHz’ - generate tones every 1 MHz. ’5MHz’ - generate tones every 5 MHz.

Default:

Usage: Defaults to previous station.

Example: PCAL=’5MHz’

PCALFR1 and PCALFR2

There are 16 pulse cal detectors in the VLBA formatters, each with the ability to detect signals from 2 bit streams. Each can be set to detect a tone at a different frequency at any multiple of 10 kHz in the baseband. PCALFR1 and PCALFR2 are arrays of 16 frequencies in kHz for the 16 detectors. ACTUALLY, UNTIL A FORMATTER UPGRADE IS COMPLETE, THERE ARE ONLY 8 DETECTORS. If a frequency of 0 is given, the detector will be used to count bits in each state. PCALFR1 applies to the first channel of the detector, while PCALFR2 applies to the second; they need not be the same. SCHED is capable of setting PCALFR1, PCALFR2, PCALXB1, and PCALXB2 automatically, and this is probably the option that most users should take. SCHED will use the automatic settings if PCALXB1(1) is not set. If the PCALFR and PCALXB values are defaulted, they will be adjusted on a scan by scan basis for any changes in observing frequency, including those requested by FREQ or DOPPLER in the SCHED keyin file.

The default will be to set up all available channels to detect, using sign bits only, first the tone near the lower edge of the band in each channel, then a second tone near the high edge of the band in each channel, and then state counts (sign and magnitude for 2 bit data) for each channel, then a third tone which is (usually) 1 MHz away from the first tone being detected. As many of these tones will be detected as possible up to a total number of detected signals that does not exceed the number of available detectors.

There is usually no problem with setting the PCALFR and PCALXB parameters when PCAL is off, so there is usually no need to turn off this default. The one exception would be if the frequencies are being switched rapidly in such a way that the PCALFR frequencies are changing. Each time they are changed, the formatter is reconfigured, which blocks data to the recording for about 8 seconds and throws the VLBA correlator out of sync. Total data loss is at least 16 seconds and can be more if there is a speedup factor greater than one or if the correlator has a hard time resyncing, which happens maybe 10-20either specify the pulse cal detector parameters and they will be kept constant or make sure the default pulse cal setup doesn’t change (keep constant the number of baseband channels, the channel bandwidth, and the pulse cal tone frequencies in the basebands (don’t change the kHz part of the frequency).

Detection of Phase cal is not currently (Oct 2001) implemented on the PCFS, although the VEX file has a way of specifying the desired detection. On MkIV telescopes this requires the installation of additional hardware, but even on PCFS controlled telescopes with VLBA hardware this is not yet supported.

Argument: An array of 16 integers, each giving a frequency in kHz.

Options: Any multiple of 10 from 0 to 16000.

Default: See above. Note that defaulting depends on whether or not PCALXB1(1) is set, not whether any PCALFRs are set.

Usage: Defaults to previous station.

Example: PCALFR1=10,10,10,10,7010,7010,7010,7010

PCALXB1 and PCALXB2

PCALXB1 and PCALXB2 determine what the pulse cal detectors measure. There are 16 pulse cal detectors in each formatter and 1 formatter at each VLBA station. (FOR NOW, THERE ARE ONLY 8 DETECTORS AT EACH STATION) Each detector can process two bit streams. In each bit stream, either counts of bits can be determined (PCALFR1=0) or a pulse cal tone can be detected. If the two bit streams are from the same (2 bit) channel, and the frequency is the same for both detectors (PCALFR1 and PCALFR2 the same), the results will be combined for a single measured amplitude and phase. The arguments are treated as character strings. They begin with a letter indicating whether to look at the sign (S) or the magnitude (M) bit. The letter is followed by a number to indicate the channel from which the bits are to come. PCALXB1 specifies the source of the first bit stream for each detector, while PCALXB2 specifies the source of the second bit stream. “Channel number” means the same quantity that is used as the index for most setup parameters. A detector can be turned off by specifying ’off’.

Most users should not need to worry about setting the pcal detection parameters. SCHED defaults to a reasonable set which is described in the section on PCALFR1 and PCALFR2.

Argument: An array of up to 16 character strings specifying Sign or Magnitude bit and the channel number.

Options: S1, S2, ... S16, M1, M2, ... M16, or off

Default: See PCALFR1 and PCALFR2.

Usage: Defaults to previous station.

Example: PCALXB1=S1,S2,S3,S4,S5,S6,S7,off, which could be used to measure 1 tone in each channel of a Mark III mode E observation.

POL

POL is used to specify the polarization of a channel. This may be used when asking SCHED to set a lot of defaults. Or it may be used to tell SCHED the polarization in cases where it is not clear from other inputs. Such cases arise when RCHAN, and LCHAN are not used AND the setup does not correspond to one in the frequency catalog..

POL should be RCP, LCP, or DUAL. One value per channel can be given. Any channels not set will default to the same value as the first so it is usually sufficient to just specify one value. If POL = DUAL for the first channel, SCHED will set alternate channels to RCP and LCP.

Actually, POL can also be R or L (meaning RCP and LCP respectively), but don’t tell anyone.

Argument: An array of polarization specifications, one per channel.

Options: RCP, LCP, or DUAL

Default: Will try to set based on other inputs or frequency catalog.

Usage: Defaults to previous station.

Example: POL=DUAL

PTINCR

PTINCR is used to set the step size for pointing patterns on the VLBA in arc minutes. A 10-point pattern is used with off, half-power, on, half-power, and off positions in azimuth, and then in the same in elevation. PTINCR gives the offset between the on and the half-power positions. PTOFF gives the distance to the off source positions. Note that the off source positions in elevation are PTOFF arcminutes off in azimuth and two times PTINCR off in elevation. This gives a smooth sequence in elevation which, at low elevation, significantly improves the baseline removal.

Argument: A real number giving the offset in arcmin.

Options: Any number but it should be near 1/2 of the FWHM of the beam.

Default: 0 - not too useful.

Usage: Defaults to previous station.

Example: PTINCR=4.0

PTOFF

PTOFF is used to set the distance to the off source position for pointing patterns on the VLBA in arc minutes. See PTINCR for more information.

Argument: A real number giving the offset in arcmin.

Options: Any number but it should be about 3 times the FWHM of the beam.

Default: 6.0*PTINCR

Usage: Defaults to previous station.

Example: PTOFF=36.0

SAMPRATE

SAMPRATE is used to set the sample rate in million samples per second. Only one value is used for all baseband channels. This is usually, but not always, twice the baseband bandwidth specified with BBFILTER. Not used for Mark II.

If not specified, twice the maximum bandwidth will be used, if BBFILTER was specified.

Note that the SAMPRATE should not be less than 2 Mbps for the VLBA (may change with Mark5C). That is the minimum track bit rate for the old tape systems and for the Mark5A and the fan-in capability was never activated so lower sample rates cannot be recorded. The user will need to specify the SP: SAMPRATE in such cases because the defaulting doesn’t deal with this restriction. It would be fixed, but the restriction will likely go away soon.

Argument: Sample rate in million samples per second.

Options: 0.25, 0.5, 1, 2, 4, 8, 16, or 32

Default: 0 - Default from BBFILTER

Usage: Defaults to previous station.

Example: SAMPRATE=4

SIDEBAND

SIDEBAND is used to specify the baseband converter (BBC) sideband for each channel. This may not be the same as the net sideband if the first mix is lower sideband, as for the VLBA it always is at 20cm and 13cm and can be at other bands. Please see FREQREF for a discussion of required parameters.

If only one value is specified, it is used for all channels.

Argument: A single character for each baseband channel.

Options: U or L

Default: 0 - must specify.

Usage: Defaults to previous station.

Example: SIDEBAND=U,L,U,L,U,L,U,L

STATION

STATION gives the names of the stations for which this group of setup parameters applies. SCHED deals with multiple stations by expanding the input group out into a separate group for each station specified. This allows the defaults picked up later, for example from the frequency catalog, to be station dependent. Therefore, if only using very generic inputs, one can lump the stations together even if their final parameters are different.

There are two defaults allowed, VLBA and ’ ’ (or none specified). If no stations are specified, the program goes through the schedule and finds all stations that are in scans that request that setup file and that have not been specified in other groups within the setup file. Those stations (just VLBA) for any VLBA stations) are added to the setup station list.

Later, the program looks for a perfect match to the station. If it finds one, it uses that setup group. If not, it checks whether the station is a VLBA station (first 4 characters in the station name are VLBA) and whether there was a station=vlba specified. If so, SCHED uses the parameters from the vlba group.

The old station=default option has been removed.

Note that you cannot specify no stations for one setup group and some specific ones for another within the same file and expect anything reasonable to happen.

Argument: Up to 30 station names of up to 8 characters each.

Options: Any valid station names. ’VLBA’ will match any VLBA station.

Default: All stations that request that setup file.

Usage: ???. Defaults to previous station.

Example: STATION=’VLBA_PT’

STRING1, STRING2, STRING3, and STRING4

STRING1, STRING2, STRING3, and STRING4 are 80-character string that will be placed in the VLBA control file without modification. This allows for new scheduling parameters provided by the on-line group to be used before they get properly built into SCHED. Comments could be passed this way by preceding them “!*” and following them with “*!”.

Argument: Any 80 character string.

Options: It just needs to be understood by the on-line system.

Default: Blank - not passed to VLBA control file.

Usage: Defaults to previous station.

Example: STRING1=’ !* Special scan *!’

SWTCHDUR

For frequency switched observations, with FRSWITCH set, SWTCHDUR gives the time spent on each switch cycle. The scan must be long enough to allow a full scan setup. 15 seconds is probably the minimum reasonable switch time. For observations to be processed on Mark III correlators, there are additional restrictions on the possible integration times; multiples of 5 seconds are OK, as are some other times.

The frequency switching mode in SCHED is seldom if ever used so should be treated carefully.

Argument: An integer number of seconds.

Options: Any integer. 15 is typical.

Default: 0 - specify it if FRSWITCH set.

Usage: Defaults to previous station.

Example: SWTCHDUR=15

SYNTH

SYNTH is a 3 element array of frequency settings for the three 2-16 GHz synthesizers for the VLBA. This is the LO for the first mix. After this mix (or 2 mixes for 1.3cm and 7mm), the signal must be in the 500-1000 MHz IF band.

Harmonic mixing issue:

Internally generated RFI tones can result from mixing of harmonics of the front-end synthesizers on the VLBA. Under some circumstances, these tones can have amplitudes of several hundred in the autocorrelations as measured using a 32 MHz baseband bandwidth and 31.25 kHz spectral channel bandwidth. Such tones cause very strong ringing across the autocorrelation spectrum without smoothing. They are also seen, more weakly, in the cross-correlations because of the concentration of power in the affected channel. All three of the synthesizers are involved in producing these tones whether or not they are actually in use. So it matters how all synthesizers are set, not just the active ones.

The tones are strongest when the frequencies that mix include the nominal output frequency of one of the synthesizers. They are also strongest, at least for the 4-8 GHz ”6cm” receiver when the synthesizers are numbers 1 and 2, both of which feed the IF converter. Other harmonics, and synthesizer 3, which usually is used for the high frequency front ends, create tones that are much weaker. A complication is that, above 8.0 GHz, the synthesizer’s main oscillator is running at half the output frequency and doubler produces the final output. A birdy is seen at the half frequency.

SCHED tries to warn of choices of front end frequencies (often obtained from the freq.dat file) that could cause problems. When SCHED is allowed to choose the frequencies of the unused synthesizers (Setup parameter SYNTH), it will try exhaustively to find benign frequencies and it should be able to in essentially all cases. So it is best to let SCHED choose.

It is not yet clear which bands can be affected when SCHED is allowed to choose the unused synthesizer settings. Any case where only one synthesizer is in use (most observations below 16 GHz) will be ok as SCHED can find benign settings for the other two. If 2 IF pairs are in use in the new 6cm receiver, it is established that one can get in trouble with this issue - that is where it was found. S/X and high frequencies where synthesizer 3 is used in the front end have not yet been tested.

Argument: 3 frequencies in GHz.

Options: N*500 +- 100 MHz and between 2 and 16 GHz.

Default: 0 - should be specified.

Usage: Defaults to previous station.

Example: SYNTH=15.9,4.1,15.9

TPMODE

TPMODE is an obsolete parameter since tape is no longer used.

TPMODE sets the number of passes at each head index position. Allowed values are 1, 2, 4, and 8. For these cases, a maximum of 32, 16, 8, or 4 heads can be used at a time. TPMODE=1 is appropriate for Mark III mode A, while TPMODE=2 is used for Mark III mode B. Setups with different values of TPMODE may be specified for a station during an experiment, but SCHED will determine the lowest value specified for the station for the whole experiment and use that for all scans. Thus during the times when the setup calls for fewer heads than could be used with the minimum TPMODE, some tracks will be left blank. This wastes tape, but saves a great deal of complexity in keeping track of where data should be recorded on the tape. It is strongly advised that all setup files for a project use the same TPMODE. Note, however, that different stations can use different TPMODES without wasting tape.

The correct TPMODE can be determined from the FORMAT, the number of bits per sample ( BITS), and the number of channels ( NCHAN. Those parameters tell how many tracks are needed per channel and, multiplied by the number of channels, how many tracks are needed per pass. For VLBA formats, that total number of tracks is divided into 32 to get TPMODE. For Mark III, observations, the total number of heads available is normally 28, although the VLBA systems can record 32 tracks in Mark III format.

SCHED will derive a reasonable default for TPMODE in almost all cases so it is not necessary to specify it.

TPMODE can be used to force a format if FORMAT is not being specified, as is reasonable in station independent setup files. A fan out will be chosen that generates the requested number of passes per head position. If the observation uses wide band, 2 head (Mark IV and VLBA4) or 2 tape (VLBA) mode, the fan out will be chosen assuming that all antennas have the 2 head/tape capability. Later, for single drive stations, the number of channels will be cut in half.

For S2 recorders TPMODE denotes the number of groups the S2 recorder can use in the desired recording mode. In other words it is the total number of recorders divided by the number of recorders implied by the mode. It must be consistent with the S2 mode implied by the number of channels and bandwidth to be record.

Argument: An integer.

Options: 1, 2, 4, or 8

Default: 0 - SCHED will generate a reasonable default.

Usage: Defaults to previous station.

Example: TPMODE=2

TPSPEED

The TPSPEED and related parameters are even more obsolete now than noted below because tape is no longer used.

TPSPEED is an obsolete form that has been replaced by TPSPEEDH and TPSPEEDL. It will cause an error message to be written. The value given will be used for TPSPEEDL.

TPSPEEDH

TPSPEEDH is an obsolete parameter because tape is no longer used.

TPSPEEDH tells SCHED the recording speed of the tape in inches per second when recording at high density. The low density record speed is specified with TPSPEEDL. SCHED uses this information to calculate where on the tape each scan is located, when to reverse direction, switch head assignments etc. The density at which the recording should be made is set by the DENSITY parameter in the tape initialization inputs.

TPSPEEDH and TPSPEEDL will default to the correct values for tapes written on VLBA, Mark III, Mark IV, VLBA4 and S2 systems. It should not be necessary to specify them and it is probably safer not to do so.

The speeds currently in use are:

67.5 ips
for low density Mark III/IV at 2 Msamp/s per track.
135 ips
for low density Mark III/IV at 4 Msamp/s per track — the “normal” speed.
270 ips
for low density Mark III/IV at 8 Msamp/s per track — the “double” speed.
66.665 ips
for low density VLBA format at 2 Mbits/s per track (with fan out etc, this may not be the sample rate).
133.33 ips
for low density VLBA format at 4 Mbits/s per track.
266.66 ips
for low density VLBA format at 8 Mbits/s per track.
40 ips
for high density Mark III/IV and VLBA format at 2 Mbits/s per track (with fan out etc, this may not be the sample rate).
80 ips
for high density Mark III/IV and VLBA format at 4 Mbits/s per track.
160 ips
for high density Mark III/IV and VLBA format at 8 Mbits/s per track.
320 ips
for high density Mark IV format at 16 Mbits/s per track — the “double–double” speed. This is not yet supported.
4.2 ips
for S2 format on high density recordings. The S2 speeds are fictitious values that make the times come out right.
6.3 ips
for S2 format on low density recordings.

The VLBA and VLA started using high density on all thin tapes on about 1 May 1996.

Note that the recording speed determines the speed up factor on playback. All playback on the VLBA correlator is done at the higher speed (160, 266.66 or 270 ips). Projects recorded at less than the highest speed will play back in less than real time. It is important that a reasonable fraction of projects have a speed up factor of more than unity or the correlator will not be able to keep up with observing.

The VLBA control file only specifies STOP, +RUN, -RUN, +REWIND, or -REWIND, and the on-line system deduces the speed to use from the format and samplerate. If SCHED has the values different from what the on-line system chooses to use, the direction and head position commands, along with tape changes, will be wrong and the project will be messed up.

Argument: A real number that is the tape speed in inches per second.

Options: Any of those listed above.

Default: Defaults to values listed above depending on recording mode.

Usage: Defaults to previous station.

Example: TPSPEED=80

TPSPEEDL

TPSPEEDL is an obsolete parameter because tape is no longer used.

TPSPEEDL tells SCHED the recording speed of the tape in inches per second when recording at low density. See the discussion of TPSPEEDH for details.

Argument: A real number that is the tape speed in inches per second.

Options: Any of those listed in under TPSPEEDH.

Default: Defaults as in list under TPSPEEDH — depends on recording mode

Usage: Defaults to previous station.

Example: TPSPEED=135

TRACK1, TRACK2, ... , TRACK7, and TRACK8

The TRACKn parameters are mostly obsolete since tape is no longer used. For Mark5A disk systems, the track concept is retained, but as if there were only one pass, so TRACK1 might still be used. But SCHED generally takes care of track assignments without input from the user.

The TRACKn parameters are arrays of track specifications for use during the nth pass at a head position. One track is given for each baseband channel. For Mark III, there is a one-to-one correspondence between baseband channels and tracks so this makes sense. For Mark III observations, the VLBA track for a channel is just the Mark III track plus 3. For many VLBA modes, several tracks are used for each channel. In these cases, the first track used for the baseband channel is specified and the on-line system determines the rest. A fanned out channel uses adjacent tracks within the odd or even groups and the lowest VLBA track used for data is 2. For example, a 1:4 fan out channel uses tracks 2, 4, 6, and 8 for the low order bit. If 2-bit samples are used, tracks 10, 12, 14, and 16 would be used for those bits. In such a case, the only track mentioned in a TRACKn parameter is 2. If a fan-in mode is used, more than one channel should be given the same track specification. Fan-in modes are not yet tested or in use.

For modes VLBA1:1, VLBA1:2, VLBA1:4, Mark III mode B with ascending frequency order (alternating sidebands), and Mark III mode E, TRACK1 can be left out. All of the TRACKn commands will default to reasonable values. This is the recommended action for most users since track assignment is an easy area in which to make mistakes. SCHED will complain and stop if it does not know how to set the tracks for the requested mode. For the Mark III modes, extra baseband channels (2 for Mode B and 1 for Mode E) can be specified and will be put on the edge tracks that are not normally used for Mark III. For Mode B, they should follow the same alternating sideband pattern as the rest of the channels.

Argument: One integer track specifications per channel.

Options: Any integer between 2 and 33.

Default: 0 which will trigger automatic assignments for many modes.

Usage: Defaults to previous station.

Example: TRACK1=4,18,6,20,8,22,10,24,12,26,14,28,16,30

TRACK2=5,19,7,21,9,23,11,25,13,27,15,29,17,31

This example is Mark III Mode B.

3.7 Satellite Initialization.

Parameters to specify satellite information can be included in a SATINIT section imbedded in the main schedule input. See the Satellite Tracking section for more detailed information on this.

Chapter 4
INSTALLING, AND RUNNING SCHED

4.1 Installing SCHED

This section is only needed if you do not have access to an installed copy of SCHED.

It is important that users obtain and use the latest version of SCHED when scheduling observations. SCHED is evolving with time to add new features, to correct bugs, to keep up with hardware changes, and to enhance its ability to prevent errors from being made in schedules, based on experience. There are typically one or two releases each year and they are announced on the VLBI email exploder. At institutions where there are several VLBI users, someone should be in charge of making sure that the latest version is available. When that option is not available, the user should check that he/she has the latest version before attempting to schedule a project.

The SCHED software, catalogs, auxiliary files, and documentation all reside in subdirectories under a parent directory. Installing SCHED involves unpacking the tar file of the distribution into such a directory. If a canned executable is available for your type of computer, it can hopefully, used as is. Otherwise it will be necessary to compile the program. The SCHED environment variable should be set to the root directory where SCHED is installed. The PGPLOT subroutine library is required. See below if you need to install it.

The installation can be tested using the Verify script in the examples subdirectory. That script runs all the examples and compares the results with results obtained at the time the release was created.

SCHED is written in FORTRAN 77 using only a few common extensions from the standard. Development has occurred on a variety of machines including VAXes, PCs, SUNs and Macs. Current development is done under Linux and Mac OSX, with pre-release testing on a Sun. Old versions were tested on Hp, SGI, IBM (AIX), and DEC Alpha, but such machines are no longer being used for SCHED as far as I know. A big “thank you” to Franco Tinarelli at Bologna for performing many of these tests. Machine dependent code has been isolated in special subdirectories under the src/Cit code directory. There are very few. All other FORTRAN files should compile without changes on a wide variety of machines. Note, however, that all current testing is under one or another flavor of unix. There has been no recent testing under other operating systems. This will only change if there is pressure to do so. Please inform the developers if you install it on something else.

Note that the usual fortran compiler on unix machines (including Macs) these days are those from the GNU Project. In the past, the compiler was g77. That works with gcc versions 3 and lower. But development of g77 is long finished. For gcc 4 and higher, you must use gfortran which was written from scratch. We are in the process of switching the support of SCHED to gfortran and have done so for various architectures as can be seen in the configure scripts. For some older versions, we may not bother switching, but simply stop supporting, for example, 32 bit machines. By stop supporting, we mean not provide configure scripts or test before releases. It is likely you could still use such machines. We will also need to migrate the spice code for spacecraft tracking before we can abandon g77 completely.

If you plan to support SCHED under more than one computer architecture, you may wish to have subdirectories under bin and point to the appropriate one in the PATH environment variable. Or you may wish to have entirely separate installations.

To install SCHED, the following steps can be followed. Users of anything but unix or linux (who don’t exist as far as we know) will have to make some modifications.

Users of Mac OSX will need to have X windows and the compiler installed. Also for full functionallity, pgplot should be installed. There are some more details at the end of this section.

Environment and PATH (unix systems):
Set the environment variable SCHED to the base directory under which SCHED will be installed. To do this type, for example, either setenv SCHED /users/cwalker/sched or export SCHED=/users/cwalker/sched depending on the shell you use. Add the bin subdirectory to your PATH, be prepared to specify the full path name when you run the program, or put a copy of the binary (or a link to it) in some directory that is in your PATH. If the plotting capabilities are used, which is highly recommended, PGPLOT will need to have been installed and the environment variables PGPLOT_DIR and maybe PGPLOT_FONT will need to be set. In Socorro, the path and environment variables can be established by adding setup_vlba and setup_pgplot to your .tcshrc.Linux (or equivalent file for other shells).
ftp the tar file:
Use anonymous ftp to ftp.aoc.nrao.edu (user ”anonymous”, password should be your full email address). cd to pub/sched. Tell ftp to do binary file transfers (type binary). List the tar files and subdirectories present. The latest version will be in a subdirectory with the highest version number. Go to that subdirectory and copy the sched.¡version¿.tar.gz to your $SCHED directory. As of Version 8.0, that tar file contains everything except the binaries for the common architectures. There will also be a binaries subdirectory which has subdirectories for several architectures which are obvious from their names (”spice” in the name implies a version with satellite tracking enabled, which may only work at the AOC). Inside the architecture subdirectory is an executable version of SCHED. If one of these works for you, you can skip compiling the program and just use it.
Unpack the tar file:
To unpack the tar file, type tar -xvf <filename> --gunzip while in the $SCHED directory. This will unload all files from the tar file, creating the necessary subdirectory structure in the process. A README file will appear in the top level directory which contains useful information on the directory structure and on installing SCHED.

Note that, after this step, a local html version of this manual will be available in the doc/sched/sched.html under the parent SCHED directory ($SCHED). Your browser will probably run much faster pointing at that version than at the version at NRAO.

Try the binary for your system:
If you downloaded an executable file, put it in the $SCHED/bin directory. Note that we are at a time of change in the computer world so there are a lot of options, not all of which are covered. Intel and equivalent machines are changing from 32 to 64 bit. GNU fortran is switching from g77 (with gcc version 3.x and below) to gfortran (with gcc version 4+). Macs have moved from PPC chips to Intel chips. And some versions of SCHED are set up to do satellite tracking with extra software not normally distributed with the package. The architectures covered are what are immediately available to the developers. The subdirectories are LINUX64 (64 bit Intel based Linux using g77), LINUX64SPICE (like LINUX64 but enabled for spacecraft tracking), and OSX_INTEL (Intel based Mac with gfortran). For a while, there may also be one or more of LINUX (32 bit Intel based Linux using g77), OSXPPC (PPC based Mac using gfortran), and SUN (SUN workstation running Solaris using f77). If one of the binaries works for you, use it. If not, you will need to recompile.
PGPLOT:
If the plotting capabilities are desired (believe me — you want them), you should make the PGPLOT libraries and the font file available. Check if your system already has them. That is fairly likely at astronomy sites. If not, they can be obtained from many repositories of open source code. But if that doesn’t work, as of July 2011, PGPLOT 5.3.1 (which is not obviously available on the PGPLOT website) is included with the SCHED distribution in the $SCHED/PGPLOT subdirectory. Simplified instructions for installation are given in $SCHED/PGPLOT/README_PGPLOT. There is extensive information on PGPLOT available from the WWW page at http://www.astro.caltech.edu/˜tjp/pgplot/. Those web pages are also included with the PGPLOT distribution. Note that PGPLOT should be built with the same compiler and machine architecture as SCHEDfor everything to function properly.

Robert Mutel provided the following suggestion if you are running into problems on a MAC with the use of the pgplot libraries (complaints about being a FAT file): Edit the PGPLOT makefile to eliminate the ranlib indexing steps, and add a ’s’ option to the ar steps (this is equivalent to indexing with ranlib, but ranlib chokes because it cannot read ’fat’ libraries, which contain both 32bit and 64 bit versions of the routines. ’Fat’ libraries seem to be created by default by ar, at least in the recent Mac OSX release.

Compiling the program:
If you need to compile SCHED , you will need to construct an appropriate Makefile and run make. There is a template Makefile (Makefile.master) showing lots of possible options and a number of simple scripts that edit the template to build Makefiles for specific cases using the line editor sed. You can either modify the template Makefile or one of the scripts to match your system configuration. Basically what you need to do with the required edits is tell make what FORTRAN compiler you use and where various required libraries reside. There are lots of comments in the template Makefile to guide the process. Once ready, run make. Many routines are compiled so it will take a few minutes. Under gfortran, there will be some warnings that can be ignored, especially about character variables being truncated.

There is some oddity that has been seen on Mac OSX (May 2008) where it is not equivalent to just type make when the Makefile is what you want and typing, for example, make -f Makefile.MacOSX. The latter doesn’t seem to work with what look to be problems finding libraries. We don’t understand it.

Note that the Makefile requires the use of GNU make. Check for GNU make on your system. It is installed on many if not most and is the standard make under Linux and OSX. If you don’t have it, it can be obtained from prep.ai.mit.edu. Also a version (probably not current) is available in the same ftp area as SCHED.

SCHED can be compiled with or without the plotting capabilities. It is highly recommended that you compile with those capabilites. To do so, you will need PGPLOT (version 5.2 or later) installed on your system. See above for more information on getting PGPLOT if you don’t already have it.

There is also a stub for the routines related to use of the JPL ephemeris, in case that code causes problems. The JPL routines are used for observations of planets, which are probably only of interest for single-dish testing of the VLBA by staff. Using the stub requires changing some comments in the Makefile. Similarly, there is a stub to avoid using the NAIF software related to satellite tracking. The normal user will use that stub because the NAIF libraries are not normally distributed with SCHED.

Testing:
The examples in the examples subdirectory can be used to test the code once it has been installed. A few outputs from each example are stored in the Stdout subdirectory. For unix systems, the routine Verify can be used to run all of the examples and compare results with those in Stdout. The output from Verify will be in the file testruns.out. Any differences are in the output from diff. It is common to have differences in items such as source positions in the last significant figure. Different machines handle rounding differently. Such differences can be ignored. Any more serious differences are cause for concern.

Some VAX FORTRAN features that are commonly supported by other FORTRAN compilers remain in the code. These features are supported by all of the compilers that we are aware of that are being used for SCHED currently. They include long variable names, in-line comments, and END DO. If you have problems with these features, please email cwalker@nrao.edu. Considerable use was made of the SLALIB (STARLINK) routines for precession, etc. These routines use long variable names so removing this non-standard feature would not be easy. (email permission to use the FORTRAN SLALIB routines has been obtained from P. Wallace, although the version under the GNU license was installed in March 2013).

If the code or any other files are moved from a unix or VMS machine to a machine using DOS or Windows, beware that the end-of-line characters are different. At least on SUN and Linux, a pair of utilities unix2dos and dos2unix can be used to fix the files. As of Dec. 2009, SCHED under Unix and Unix-like operating systems can read DOS format files.

We are always interested in hearing about people’s experiences installing SCHED on various machines. If you have problems, or even success on machines other than those listed earlier, please let us know (email to cwalker@nrao.edu). We would be especially interested if someone ports SCHED to a non-unix, or unix-like (eg Linux) operating system. SCHED was supported under VMS and DOS in the past and the coding style hasn’t changed, so a port to such operating systems would probably not be difficult.

A recent experience installing SCHED on a MacOSX 10.5.4 system showed the need to be careful about compiler versions. That version of OSX uses version 4.0.1 of the gcc compiler. You have to use gfortran, a Fortran 95 compiler, with gcc versions above 4.0 and g77 with lower gcc versions. PGPLOT was loaded from the Fink, as were both g77 and gfortran, and the PGPLOT was first built with gfortran. The build of SCHED only went smoothly after switching to gfortran for SCHED. There will be similar issues wherever the switch from gcc 3 to 4 occurs. For some details of my first install of SCHED on a Mac in 2003, see Appendix B.8.

4.2 Running SCHED

4.2.1 Running SCHED under UNIX or LINUX

To run SCHED on a UNIX machine such as a SUN or a PC under LINUX, prepare the keyin file without system level commands. Then type, for example,

sched < input.key

Alternatively, if plotting is wanted, for example, type:

sched  
<SCHED will write a number of instructive lines>  
* plot schedule=input.key /

where the SCHED executable file is assumed to be in the default directory or path and the SCHED input commands are in input.key in the default directory. The “<” pipes the information in input.key to SCHED. The “*” is the prompt from SCHED. Remember that, in UNIX, file names and commands are case sensitive. Also, there is a complication for users of the tc shell for versions after mid 1995: there is a built-in shell command “sched” that the shell takes instead of running SCHED. So to use SCHED, either alias “sched” to mean this program or else specify the full path name of the execute module. The files output by SCHED will appear in the default directory.

If your version of SCHED is linked with the PGPLOT libraries (has plotting capability), you will need to set the environment variables PGPLOT_DIR to the location of the PGPLOT libraries and PGPLOT_FONT to the location of the PGPLOT font files. If you use PGPLOT for other reasons (programming, DIFFMAP etc), then this is likely to be part of your standard setup.

4.2.2 Running SCHED on a VAX with VMS

Note that I am not aware of anyone using SCHED on VAXes any more.

To run SCHED on a VAX, make a VMS command file, called INPUT.COM for example, which begins with a VMS command that causes SCHED to be executed. For systems with a fully installed Caltech package, the command “$ SCHED” should work. Otherwise use a command of the form “$ RUN UMA3:[VPGM.CIT.VLB]SCHED”, where you will need to substitute the correct directory specification. The command file should end with “$ EXIT”, although this is not necessary. The SCHED command file is run by typing, for example,

@INPUT.COM

The files output by SCHED will appear in the default directory.

SCHED has not been tested under VMS since the plotting capabilities were added.

It has been a very long time since I was aware of anyone running SCHED on an MS-DOS machine, or a Windows machine for that matter.

To run SCHED on a PC (MS DOS), prepare the input file without system level commands. Then type, for example,

\CODE\SCHEDB < INPUT.KEY

where the SCHED.EXE executable file is assumed to be in the CODE directory (substitute whatever is correct for your system) and the SCHED input commands are in INPUT.KEY in the default directory. The “<” pipes the information in INPUT.KEY to the program (note the similarity to UNIX). The files output by SCHED will appear in the default directory.

It has been a long time since SCHED was ported to DOS. It has never been ported to Windows. It seriously outgrew DOS, but should work in Windows if someone were to take the effort to install it.

4.3 Distribution of Schedule Files

Once SCHED has been used to make schedules for an observation, those files need to be sent to the stations, usually by way of a distribution center at NRAO or in Europe. When time for a project is allocated, instructions for how to accomplish this will be provided.

4.4 Related Programs

This section briefly describes other programs that may be of use when using SCHED. The descriptions of SKEDCONV, PC-SCHED, and UPTIME have been removed as they are no longer in use. That leaves only the geodetic scheduling program SKED which is still the primary tool for scheduling geodetic project.

SKED
Originally the scheduling program for Mark III, SKED is now the standard program for scheduling geodetic VLBI observations. It produces SKED or drg files that are converted to snap files by DRUDG. It also produces VLBA control files for geodetic projects. It has sophisticated automatic scheduling capabilities, well beyond what is available in the optimization modes of SCHED, for geodetic projects. Contact the GSFC VLBI group for more information.

4.5 Release Instructions.

This section is mainly for the primary SCHED developer. It describes the process of making a SCHED release. It is written to allow the main lines to be cut and pasted into a terminal to accomplish the steps. I have not set up a script because considerable interaction and checking is normally required.

This section is derived from a separate file called Release_instructions that is no longer being maintained.

Before a release:

Be sure that the other developers have committed anything that they want included in the release.

Make sure VERSION and VERNUM in versched.f are up to date. Make sure the version on the manual first page is current.

Make sure sched_work is synced with the svn repository. This should include the results of updating the manual. Note that sched_work is my development directory. You may have something different.

Make sure that the leap seconds in $SCHED/src/Sla/dat.f and in $PLANET_DATA/naif0007.tls (or equivalent like naif0010.tls) are up to date. If there is a change in dat.f, update the slalib.a in my other programming areas as they might affect the pointing and gain programs, although I’m not sure if any actually are sensitive to the leap second. The slalib library for those programs is in svn at https://svn.aoc.nrao.edu/repos/VLBA/rcwlib/trunk/slalib. The other programs are found starting at https://svn.aoc.nrao.edu/repos/VLBA.

Setup files:

Update the setup files from the master if needed. Note that the following will replace most of the setup files, but there are a fair number, mostly for the lba, that are not built by makesetup, so do not do a global delete of the .set files. Note that the .set files are in the svn repository, so run a commit after running makesetup. If you do inadvertantly delete the lba setups, they can be recovered from the repository.

cd $SCHED/setups  
makesetup

Station, frequency, and messages files:

These catalogs are maintained in pieces in separate subdirectories to the catalogs directory. There are files for the US, DSN, EVN etc. Different subdirectories are maintained by different people. There is an Update script in the base catalogs directory which does the file merge. You can look in there to see what gets merged to form the stations, freq, and messages files. Run Update when all segments are up to date:

cd $SCHED/catalogs  
Update

Source and location files:

Install the latest source and locations catalogs from the geodetic community. The source files can be found either by contacting Goddard (David Gordon) and Leonid Petrov (Radio Fundamental Catalog), or by looking for “GSFC VLBI” or “Petrov VLBI” with a search engine. The locations file is from Goddard (also Gordon).

The latest source files, with their names that identify the release, should put in $SCHED/catalogs while the locations file with its name including a release identifier should be put in $SCHED/catalogs/Master_NRAO. Then the symbolic links sources.gsfc and sources.rfc in $SCHED/catalogs and the link locations.gsfc in $SCHED/catalogs/Master_NRAO should be updated. The final locations.dat file in $SCHED/catalogs will include both this downloaded file plus contributions from other places. It is built when Update is run in $SCHED/catalogs, which updates most of the catalogs. All of the new files and links should be added to svn. If SCHED complains about duplicate station data, it might be that a station that formerly came from one of the other locations files has been added to the geodetic solution. The geodetic solution should be given preference. Watch out station data based on few observations. They might have unreasonably large rates. This happened with the new data for the DSN stations DSS14 and DSS63 in the 2015feb release, and we reverted to using the old data in stations_DSN.

The old catalogs can be moved out of the main /schedb area. I have put a lot of such stuff in  cwalker/files/sched_ARCHIVE_nonSVN/catalogs. The new catalogs should be added in svn. After copying (not moving) them to some storage location, the old ones should be deleted with svn.

Note that updating the source and locations files used to involve reformatting the ones acquired from the geodetic groups, often a complicated task especially if formats changed. But now both GSFC and Petrov are providing files in the correct format to use directly. The reformatting of the files used to involve the programs NEWLOC and NEWLOC in $SCHED/RELATED_CODE, but those should no longer be needed.

Test and produce standard output files:

Once the code is thought to be working, go to the examples directory and run the Verify script. That will run all of the examples and compare the output with the last standard output set, which is kept in the Stdout subdirectory. Once satisfied that all differences are understood, run Newstd to update the standard outputs. Note that both of these scripts will need to be maintained if changes or additions are made to the examples suite.

Check the crd. files with cksched on a Sun. There is a script Legacy_cksched that can be used to run cksched on all crd files in a directory. It should be run on the updated Stdout directory as that has a sample from each example, rather than all. Running in the examples directory would create a huge amount of output.

Check the vex files on a 64 bit Linux machine with Check_vex. This runs /home/swc/software/VLBADIFX-TRUNK/bin/vexpeek on all of the vex files. Since there is only one per example, it does not matter if this is done in examples or in examples/Stdout. Note that the error messages go to standard error so they do not go through a simple pipe, such as to less. Use the construct Check_vex |& less

Try plotting, probably using example egplan.key.

Compile for multiple architectures:

Compile and link SCHED for each target architecture. Run Verify in the examples directory after each compile and check testruns.out] to make sure it works. The compilations are without satellite tracking unless otherwise noted. Doing multiple compilations has been useful for finding bugs that don’t affect all compilers. Currently I support SCHED on the architectures listed below. Note that the environment variables $PGPLOT_DIR and $PGPLOT_FONT may need to be changed depending on where PGPLOT is stored for that compile (probably different for g77 and gfortran on Linux, for example).

LINUX64GFORTRAN 64 bit Intel linux compiled with gfortran (noatak).

LINUX64SPICE    64 bit Intel linux compiled with g77 and including satellite tracking.

LINUX64         64 bit Intel linux without spice.

OSX_INTEL       Intel Mac compiled with gfortran

SUN             Sun Solaris compiled with f77. Note some Sun’s have too little memory for the default parameter settings.

To compile on a given machine, login to that machine.

To summarize:

cd $SCHED/src  
configureLinuxSpice64  
make clean   (gmake clean on the Sun)  
make         (gmake on the Sun)  
cp ../bin/sched ../bin/LINUX64SPICE/  
cd ../examples  
source ./Verify  
less testruns.out

Try a plot.

In the Verify step, look for unexpected differences. Recorded run times will be different, and often there will be last-digit differences due to different rounding schemes. Those are ok. but anything else could be a sign of trouble.

Document the release:

The manual should have been kept up to date while programming was in progress. Fill any gaps.

Write a release note. This will be mainly a link to the manual update section. It will be sent to the vlbi exploder.

Check the README and README.ftp files in $SCHED to be sure that they are current.

Set environment variables to aid the release:

Set the NEWVER in the window where this work is being done so that script segments below can be used with a cut-and-paste Also check a couple of places below (other machines) where the version number is also needed. Note that the tar files are kept separately from the development version of SCHED. If maintaining SCHED anywhere except cwalker’s area, establish an area for that.

setenv NEWVER 11.3  
setenv TARDIR /users/cwalker/files/sched_ARCHIVE_nonSVN/TARFILES

Prepare the Manual:

First, be sure that the manual is as up-to-date as you can reasonably make it. That said, there are sections that still need work as time allows. The manual is the equivalent of over 300 pages so maintaining it is a significant job. The most important parts to keep current are the parameter descriptions and that the summary indexes of those descriptions.. The htlatex scheme does not automatically produce complete indices of the parameters as latex2htms did, so the summary lists are now much more important but easy to forget. Also, make sure the list of changes in the release notes section is complete. It is best to keep the manual up-to-date whenever changes are made, not to wait until just before a release.

The examples in the manual are grabbed from ../examples starting from where latex is being run. So this should be done in $SCHED/doc, the normal place in a distribution, so the examples will be from $SCHED/examples. Note that these are not the copies of the examples that will be put (see below) in $SCHED/doc/sched/examples.

Process the manual. The manual is in file $SCHED/doc/sched.tex which is configured for processing by latex, pdflatex, and htlatex. latex produces a .dvi file which can then be used by various programs to produce other formats. But this is probably not the way to go. However, it is useful to run bare latex first to shake out any problems in the file. It seems to catch some errors that the others miss. Note that latex or pdflatex will be need to be run at least 3 or 4 times to get all the references right. htlatex does three passes of the latex step regardless. pdflatex directly produces a monolithic pdf file with active hyperlinks. htlatex produces the HTML files with chunking to the level specified in the call as shown below. The html files produced by htlatex are the standard form for distribution of the manual. The pdf file from pdflatex can be considered optional.

Note that the various files produced by latex, pdflatex, and htlatex are not necessarily compatible, (so I’ve been tole) so it is a good idea to delete them before running a different program. The script latexclean can do the cleanup as shown below. That is certainly something to try if there is a crash for non-obvious reasons.

Note that, until Jan. 2015, the HTML manual was prepared with latex2html, but that program is no longer being supported and stopped working at the AOC. So we converted to htlatex, which involved retyping most of the hyperref references in the text. We cannot easily go back. In the process, the automatically-generated names of the html pages, and the number of such pages, changed. Any references in external documents are going to have to change.

For a release, both the .pdf and HTML can be made using the sequence below. Note that htlatex makes the .html files in the doc area, then copies, not moves, them to the desired subdirectory specified in the third argument — sched in this case. So the /bin/rm *.html command below is to clean out the unneeded files in the doc directory.

The files produced by htlatex that included sections that used

subsubsection in the tex file (all of the parameter descriptions!) will have, by default, a very tiny font for the section headers — much smaller than the font used for the rest of the text. It’s hard to believe that someone would set that up, but they did. The cure identified so far is to add the following line to the sched.css file in $SCHED/doc/sched. I think it can go anywhere, but I’ve been putting it in as the second to last line:

h5.subsubsectionHead{font-size:150%;}

pdflatex will leave the sched.pdf file in the doc area. The html files are prepared with htlatex. The ”sec-filename” in the example causes the .html node names to be based on the section headings, not just a sequence number. The ”3” controls how finely the manual is chunked into multiple html files. The ”3” shown seems to be a reasonable choice, although some of the files were multiple files in the latex2html days. Naming the output files makes for referable names that won’t keep changing. The -dsched/ argument causes the .html files to be copied to the sched subdirectory, after which the originals in the current area (doc) can be deleted.

cd $SCHED/doc  
latexclean sched  
latex sched.tex        (correct any errors found)  
latexclean sched  
pdflatex sched.tex     (optional; may need several repeats to get links right)  
latexclean sched  
/bin/rm sched/*.html   (cleans out old files)  
htlatex sched.tex "html,3,sec-filename" " " "-dsched/"  
/bin/rm *.html  
cd $SCHED/doc/sched  
emacs sched/sched.css        (Add the line as described above.)  
ln -s sched.html index.html  (To help some old bookmarks)

The HTML files will be expecting to find copies of the examples and catalogs in appropriate subdirectories of the sched directory to allow simple links. So update them. Don’t worry about setups here for now. Give user write privileges to make other maintenance easier. Some of the catalogs are write restricted in the $SCHED/catalogs area to help prevent modifications to the derived files produced by Update

cd $SCHED/doc  
/bin/rm -r sched/catalogs/*  
/bin/rm -r sched/examples/*  
tar cf - ../catalogs/sources.*     ../catalogs/rfc*  ../catalogs/freq*.dat \  
         ../catalogs/stations*.dat ../catalogs/locations.dat \  
         ../catalogs/peak*.cmd     ../catalogs/linefreqs.dat \  
         ../examples/*.key         ../examples/*.com \  
         ../examples/*.set         ../examples/egcentsrc.dat \  
            | (cd sched; tar xfp -)  
chmod  u+w sched/catalogs/*

Make the release version:

Put together a new directory tree to hold the release. This will be very similar to the development version, but will not evolve after the release, and will not contain some of the extra baggage of old files etc that bloat the size of the development area.

Make a directory for the new version. In this case it in in the files subdirectory of my home area.

setenv SCHEDNEW ~/files/sched_$NEWVER  
mkdir $SCHEDNEW  
cd $SCHEDNEW

Check out the current SCHED from svn. It lands in a subdirectory, so move it up, including the .svn files. Don’t be alarmed about messages indicating sched/. and sched/.. can’t be moved.

svn checkout https://svn.aoc.nrao.edu/repos/sched/trunk/sched  
mv sched/* .  
mv sched/.* .

Copy over the examples/Stdout files, the execute modules, the setup files, the html manual, and PGPLOT installation stuff, none of which are under svn (they are fast changing, bulky, and can be derived from files that are in svn). The –delete deletes files on the receiving side that are not on the sending side and is useful when updating, say, a beta release that is not being done from scratch.

rsync -auv --delete --exclude ".svn" $SCHED/bin  $SCHEDNEW  
rsync -auv --delete --exclude ".svn" \  
     $SCHED/examples/Stdout $SCHEDNEW/examples  
rsync -auv --delete --exclude ".svn" \  
     --exclude "AAA_OLD" $SCHED/setups $SCHEDNEW  
rsync -auv --delete --exclude ".svn" $SCHED/doc/sched $SCHEDNEW/doc  
rsync -auv --delete --exclude ".svn" \  
     --exclude "*.o" $SCHED/PGPLOT $SCHEDNEW

Will need $SCHED set to $SCHEDNEW to run Verify.

setenv SCHED $SCHEDNEW

Do a compilation to be sure all is there and run Verify to make sure it works. Then clean out the examples directory using schclean "*" to avoid bloating the tar file.

Test the completeness using an rsync dry run. The release directory was filled with an svn checkout and some limited rsyncs, so it could have missed something. Also if some iteration happened, it might not be complete. Note that output lines that end with a / are just an indication of having entered the directory. They don’t indicate a missing file. Some non-svn files may show, like the latex temporary files.

rsync -auvn --exclude ".svn" --exclude "TEST" --exclude "*.o" \  
   --exclude "*TEMP*" --exclude "*OLD*" --exclude "RELATED_CODE" \  
   --exclude "*~" --exclude "*old*"  --exclude "*save*" \  
   --exclude "*new*" \  
   ../sched_work/* .

Make the tar file:

Make the distribution tar file. First be sure there are no old copies in the archive and ftp areas. Also go through the SCHED directory structures weeding out excess files that don’t want to end up in the tar file. The tar command below will also omit many that are not needed. As part of this, be sure to clean out the Verify output with schclean "*" in the examples subdirectory. Otherwise the tar file will much bigger than necessary.

Note the --excludes include the lib directory which has the NAIF software. Without that, the satellite version cannot be linked. Without that, anyone wanting to do satellite tracking will need the AOC version or a special export. Also the RELATED_CODE directory is excluded as users shouldn’t need it. But the SCHED maintainer will. The PGPLOT directory is included because users may well want it. Note that the binaries will be included.

cd $SCHEDNEW/examples  
schclean "*"  
cd $SCHEDNEW  
tar --exclude "bin/sched" \  
    --exclude ".svn" --exclude "*.o" --exclude "*~" \  
    --exclude "lib" --exclude "core*" --exclude "TEST"  \  
    --exclude "RELATED_CODE" \  
     -cf $TARDIR/sched_$NEWVER.tar .  
gzip $TARDIR/sched_$NEWVER.tar

Test the release:

This will not have the NAIF software so it will not be the internal release. Clean out sched_temp first if needed. Unpack the source distribution tar file into /users/cwalker/files/sched_temp (or wherever you want - but adjust SCHTEST accordingly) and test the compilation without the satellite stuff. Use the makefile that does not use the spice package (run configureLinux) Check testruns.out at the end. This is best done in a sacrificial window so the changed environment variables don’t haunt you later.

setenv SCHTEST /users/cwalker/files/sched_temp  
setenv SCHED $SCHTEST  
cd $SCHTEST  
chmod u+w $SCHTEST/catalogs/*  
/bin/rm -r *  
tar -xvf $TARDIR/sched_{$NEWVER}.tar.gz --gunzip  
cd src  
configureLinux64  
make  
cd ../examples  
Verify

Maybe run the ”Dry Run” rsync above to check for completeness.

Kill the window to dump the unwanted $SCHED etc. or at least:

setenv SCHED /users/cwalker/files/sched_work

Put files on the ftp site:

Put the tar file on the ftp site. Maybe some day, make a web site for this. Note that the binaries are in the tar file now.

mkdir $FTP/sched/sched_$NEWVER  
cp $TARDIR/sched_$NEWVER.tar.gz  $FTP/sched/sched_$NEWVER/

Copy over README.ftp if it has changed.

Put the documentation on the personal web pages:

This is to create the copy of the web pages currently available at www.aoc.nrao.cwalker/˜c
     walker/sched/sched.html. My web pages are staged to a separate area where I can work on them, then copied to the public_html area. That copy happens as part of the backup job run twice per day using cron. While doing the update, it is a good idea to clean up the staging area and html area. They tend to accumulate unneeded old files for old versions.

The instructions here are based on the machine names for R.C. Walker. They may change for a new maintainer.

Note that the files will all be in a directory numbered for the release. The file where users will look is a symbolic link to the generic file sched.

setenv WEBDIR /home/noatak/cwalker/webnrao  
cd ~  
mkdir $WEBDIR/sched_$NEWVER  
cp -R $SCHEDNEW/doc/sched/* $WEBDIR/sched_$NEWVER/  
cd $WEBDIR  
/bin/rm sched  
ln -s sched_{$NEWVER} sched  
cd $SCHED

Announce the release and get it installed at the AOC:

Send the email announcement to: vlbi@nrao.edu,scistaff@nrao.edu,analysts@nrao.edu,pperley@nrao.edu, vlbaops@nrao.edu,vlbatests@nrao.edu

Announcements of preliminary releases can go to: nmsci@nrao.edu,analysts@nrao.edu,pperley@nrao.edu,vlbaops@nrao.edu

Also, at some point, include the other SCHED developers: small@jive.nl,campbell@jive.nl,c.reynolds@curtin.edu.au,alef@mpifr-bonn.mpg.de

The AOC release is in software areas where I do not have write privileges. Tell the computer people (helpdesk) to place the update in the computer areas. Include the following information in email to them (adjust version number):

The new release is in /users/cwalker/files/sched_11.3

The executables (sched, schclean) are in machine specific subdirectories under bin. They go in /usr/local/bin. For the in-house linux64 versions, use the one with the SPICE libraries (LINUX64SPICE). These support spacecraft tracking. We no longer support LINUX32 or MACPPC.

The manual is in doc/sched/* and goes in http://www.aoc.nrao.edu/software/sched/*

The catalogs and setups are in separate directories that go in /usr/local/sched. Note that the subdirectories in the catalogs directory (Master_NRAO etc) should not be included.

Make a tagged version in svn:

There is demand for tagging the releases, so here are the instructions. This basically marks a revision as the tag (release). To do so from trunk ( There is a slight variation for a branch origen):

svn copy https://svn.aoc.nrao.edu/repos/sched/trunk \  
         https://svn.aoc.nrao.edu/repos/sched/tags/sched_$NEWVER \  
         -m "Tagging SCHED $NEWVER for maintenance"

To backfit a tag to other than the latest version:

svn copy -r 276 https://svn.aoc.nrao.edu/repos/sched/trunk/sched \  
         https://svn.aoc.nrao.edu/repos/sched/tags/sched_9.3 \  
         -m "Tagging release 9.3 of sched."

SVN branch and other SVN info:

OPTIONAL (I normally don’t do this)

Under some circumstances, it might be useful to have a full copy of a release that is maintained with svn. This involves making a branch or tag (I think they are equivalent), and then checking it out to a new directory. Then to be really useful, the items not maintained in svn should be copied in. I tried this with my first post-svn release in 2009, but found it too much work to maintain, so abandoned the practice. But the instructions are here in case. They have been edited since they were last tried, so watch for gotchas.

Make the branch - just a different directory than the tag.

svn copy https://svn.aoc.nrao.edu/repos/sched/trunk \  
         https://svn.aoc.nrao.edu/repos/sched/branch/SCHED-$NEWVER \  
         -m "Branching the 8.0 release of SCHED"

To make a corresponding development area for the branch:

setenv SCHEDBASE ~/files/sched_branch$NEWVER  
mkdir $SCHEDBASE  
cd $SCHEDBASE  
svn checkout https://svn.aoc.nrao.edu/repos/sched/branch/SCHED-$NEWVER/ .

Don’t drop the period at the end of the last command (= current directory)

Copy over the examples/Stdout files, the execute modules, and the html. The exclusion of .svn files shouldn’t be needed, but just in case...

cd $SCHEDNEW  
rsync -auv --exclude ".svn" bin  $SCHEDBASE  
rsync -auv --exclude ".svn" examples/Stdout $SCHEDBASE/examples  
rsync -auv --exclude ".svn" doc/sched $SCHEDBASE/doc

Some SVN HINTS:

In order to ignore some files in svn status etc. Note the ”.” on the end of the second one. ignore.txt is needed for the second form.

cd examples  
svn propset svn:ignore "*" Stdout  
svn propset svn:ignore -F ignore.txt .  
cd ../doc  
svn propset svn:ignore "*" sched

Developer advice:

If you are a developer and have an svn maintained version and wish to update the items not in svn, such as the html manual, the Stdout example outputs, or the setups (derived from makesetup), it might be easiest to download and unpack the tar file into a new directory, then rsync the desired stuff to your development area.

Chapter 5
RELEASE NOTES

5.1 Recent Releases

5.1.1 Version 11.6 development

5.1.2 Version 11.5 (released September 2018)

5.1.3 Version 11.4

The nominal release date for this version is March 12, 2015.

5.1.4 Version 11.3

5.1.5 Version 11.2

5.1.6 Version 11.0

5.1.7 Version 10.2

Version 10.2 was released near July 11, 2012. It mainly provides support for the new wide C band receiver and switch control systems on the VLBA, improved support for the new wide bandwidth backends and recorders, and initial support for VLBI at the VLA/WIDAR.

5.2 Old Releases

5.2.1 Version 10.1

This version was released on or about Feb. 14, 2012. It addresses a number of issues related to the new wideband system on the VLBA.

5.2.2 Version 10.0

5.2.3 Version 9.4

This version brings in many new capabilities including support for multiple phase centers on the DiFX correlator, automatic insertion of geodetic segments (DELZN), enhancement to DWELL to allow scans to start before the slowest antennas arrive, and support for the new wideband hardware (RDBE and Mark5C with hooks for the DBBC). The release will likely be on Jan. 14, 2011.

5.2.4 Version 9.3

This version corrects an error in the reference dates in the locations.dat file. There are also some code updates and more configure scripts for gfortran on Linux. Version 9.3 was released on March 23, 2010.

5.2.5 Version 9.2

This was version 9.1 during development. Version 9.2 was released on March 10, 2010.

5.2.6 Version 9.0

This is a beta release available locally in Socorro. It was released on Oct. 14, 2009. Note that beta releases are not necessarily full releases with all possible binaries and all the documentation fully updated. But they are a snapshot of the development version so any new features will be in the next main release.

5.2.7 Version 8.1

We needed to get the GBT catalog corrections and the Vex file fix into the wild.

5.2.8 Version 8.0

Released on Dec. 13, 2008.

5.2.9 Version 6.05

Version 6.05 is a minor revision from version 6.04. The main issue addressed was a problem where sources between 0 and -1 deg dec had the wrong sign of dec in sources.vlba. There are also a couple of bug fixes in the plot routines and new Arecibo entries in freq.dat. It was released on June 8, 2006.

5.2.10 Version 6.04

Version 6.04.1 is version 6.04 except that a the sources.vlba catalog has been fixed to remove duplicate aliases and to restore a very small number of aliases that were lost in 6.04.

The major enhancement in the 6.04 version is the addition of OPTMODE=HAS which can be used to construct certain kinds of schedules automatically from an input schedule that is basically a source list. In this mode, SCHED tries to spread the scans on each source in hour angle subject to various constraints. In its current form, it is most useful for scheduling survey type observations. Future enhancements will make it more useful for phase referencing and other modes. For more information, see the OPTMODE description.

This release includes everything that was in the 6.03 mini-releases that occurred since 6.02. Those mini-releases were not sent to the broader community and were intended mainly to make available the new OPTMODE=HAS for use by the VIPS survey, which started before we could do a proper SCHED release.

Change log:

Version 6.04.1:

Version 6.04:

5.2.11 Version 6.02 (Released 29 July 2005)

5.2.12 Version 6.01

5.2.13 Version 6.0 - Released March 8, 2005

This includes many items that were in the 4 Oct 2004 release made in the AOC.

5.2.14 Release of 18 September 2003.

5.2.15 Release of 02 July 2002.

5.2.16 Release of 16 October 2001.

5.2.17 Release of 12 February 2001.

It seems that we are having teething problems with the new reference pointing capabilities. This release makes available some important fixes required for 3mm VLBA projects. But it does not have some fixes for VEX problems that will affect CMVA runs. So there will be another release in a couple of weeks. The changes here are not significant for users not attempting reference pointing with AUTOPEAK or other mechanism that invokes setup files with FORMAT=NONE. If you don’t need this one right now, it is recommended you wait for the VEX fixes.

5.2.18 Release of 30 January 2001.

This was an emergency release to fix the problem with the Doppler calculations when using the automatic reference pointing scan insertion. This problem would be fatal for schedules using spectral line sources and AUTOPEAK. Given that most reference pointing sources are line sources, this means most 86 GHz projects on the VLBA. Other types of projects are not affected.

5.2.19 Release of 12 January 2001.

5.2.20 Release of 28 April 2000.

5.2.21 Release of 1 July 1999.

5.2.22 Release of 1 Dec. 1998.

5.2.23 Release of 30 March 1998.

5.2.24 Release of 18 Nov. 1997.

5.2.25 Release of 18 August 1997.

5.2.26 Release of 1 Aug. 1997

5.2.27 Release of 10 Feb. 1997

5.2.28 Release of 14 Jan. 1997

5.2.29 Release of 4 Dec. 1996

5.2.30 Release of 26 June 1996

5.2.31 Release of 13 Apr 1996

5.2.32 Release of 22 Feb 1996

This is a slightly modified version of the SCHED that was released within NRAO in December 1995.

This version included a number of evolutionary changes made up to November 1995. In that month, the VLBA OBSERVE (GNOMES) project was cancelled and it became clear that SCHED had much more of a future than expected. Many changes, including addition of plotting and dwell time scheduling, along with massive changes in internal structure for both maintainability and for eventual Mark IV support, were made. Also the help file was renamed the manual, formated for LaTeX and html, and to a large degree, rewritten. It is now this document.

The evolutionary changes before November 1995 were:

The big rewrite included:

5.2.33 Release of 16 May 1995

Consult the old sched.hlp file for changes before 1995. It can be obtained from Craig Walker.

5.3 Wish List

This is a list of desired program changes, fixes or enhancements. Note that the list is not all that well maintained, so some items may have been addressed, but not taken out here.

Appendix A
APPENDICES

A.1 Station Codes

The following is the list of station codes used in VLBA and Global Network scheduling as of Feb 1998. It is a copy of BarryClark’s file. Note that normally only the two letter code is used for the scheduling process. This list clearly needs an update.

        Suggested 2-letter Observatory codes  
(Also indicated are telescope codes for multi-telescope observatories)  
Codes are capitals in machine readable usage.  The capital/lowercase  
pairing below is used for readable concatenations on schedules, etc.  
Table updated 96oct29.  
------------------------------------------------------  
Code      Location               Normal array   Schedule server  
Ap      Algonquin, Canada  
Ar      Arecibo, USA                            Socorro  
As      Alice Springs, Australia     Sheve  
At      Culgoora, Australia (ATCA)  
Ba      Bangalore, India  
Bl      Bear Lakes, Russia  
Br      Brewster, USA                VLBA       Socorro  
Ca      Cambridge, UK                MERLIN  
Cb      Cambridge, UK (Ryle)  
Cd      Ceduna, Australia                       ATNF  
Ce      Cebreros, Spain  
Ch      Chilbolton, UK  
Da      Darnhall, UK                 MERLIN  
De      Defford, UK                  MERLIN  
Dw      Dwingeloo, Netherlands                  Bologna  
Eb      Effelsberg, Germany (VLBA system)EVN        Bologna  
Ef      Effelsberg, Germany (MkIV system)EVN        Bologna  
Ev      Evpatoriya, Ukraine  
Fd      Fort Davis, USA              VLBA       Socorro  
Ft      Fortaleza, Brazil  
Gb      Green Bank, USA                         Socorro  
   GB=140’, GBT=100m, GB85=85-3, GBTT=85-1  
Gc      Gilcreek, USA  
Gg      Goddard, USA  
Gm      Narayan Gaon, India (GMRT)  
Gn      Green Bank, USA              NAVY  
Go      Goldstone, USA               DSN  
   GO=70m, DS15=34m, DS12=Venus  
Gz      Goldstone, USA               Tracking  
Hc      Hat Creek, USA (BIMA)  
Hh      Hartebeesthoek, S.Africa     Sheve      ATNF  
Hn      Hancock, USA                 VLBA       Socorro  
Ho      Hobart, Australia            Sheve      ATNF  
Hs      Haystack, USA                CMVA  
Hy      Hyderabad, India  
It      Itapetinga, Brazil  
Jb      Jodrell Bank, UK             EVN, MERLIN Bologna  
   JB=Lovell, JB2=Mark2  
Ka      Kashima, Japan                          Mitaka  
   KA=26m, KB=34m  
Kk      Kokee Park, USA              Navy  
Kl      Kalyazin, Russia  
Kn      Knockin, UK                  MERLIN  
Kp      Kitt Peak, USA               VLBA       Socorro  
   KP12=NRAO 12m  
Ks      Kiruna, Sweden  
Ku      Kauai, USA                   Defunct  
Kw      Kwajalein, USA  
La      Los Alamos, USA              VLBA       Socorro  
Ma      Matera, Italy  
Mc      Medicina, Italy              EVN        Bologna  
Md      Maryland Point, USA          Defunct  
Mg      Mount Graham, USA  
Mh      Metsaehovi, Finland          EVN        Bologna  
   MH=15m, MHGE=Geodetic  
Mk      Mauna Kea, USA               VLBA       Socorro  
Mm      Mauna Kea, USA               JCMT  
Mo      Mojave, USA                  GEO  
Mp      Siding Spring, Australia                ATNF  
Ms      Mauna Kea, USA (CSO)  
Na      Nancay, France  
Nb      Nobeyama, Japan (mm array)  
Nl      North Liberty, USA           VLBA       Socorro  
No      Nobeyama, Japan                         Mitaka  
   NO=45m, NO6=6m  
Nt      Noto, Italy                  EVN        Bologna  
Ny      Ny Alesund, Norway  
Nz      Green Bank, USA              Tracking  
Oh      O’Higgins, Chile  
On      Onsala, Sweden               EVN        Bologna  
   ON=20m, ON85=85’  
Oo      OVRO 130’ USA                CIT  
Ot      Ooty, India  
Ov      Owens Valley, USA            VLBA       Socorro  
   OVMM=OVRO 10m, using OV transports  
Pa      Parkes, Australia            Sheve      ATNF  
Pb      Plateau de Bure, France  
Pe      Penticton, Canada  
Pt      Pie Town, USA                VLBA       Socorro  
Pu      Pushchino, Russia  
Pv      Pico Veleta, Spain  
Qb      Quabbin, USA                 CMVA  
Ri      Richmond, USA                Defunct  
Ro      Robledo, Spain               DSN  
   RO=70m, DS61=32m, DS65=High gain 32m  
Rz      Robledo, Spain               Tracking  
Se      La Silla, Chile (SEST)  
Sc      Saint Croix, USA             VLBA       Socorro  
Sh      Sheshan (Shanghai), China    EVN        Bologna  
Sm      Simeiz (Crimea), Ukraine     EVN        Bolgona  
St      Santiago, Chile  
Sv      Svetloye, Russia  
Ta      Tabley, UK                   MERLIN  
Ti      Tidbinbilla, Australia       DSN  
   TI=70m, DS45=34m  
To      Toulouse, France  
Tr      Torun, Poland                EVN        Bologna  
Tz      Tidbidbilla, Australia       Tracking  
Ud      Usuda,Japan                             Mitaka  
Ur      Urumqi, China                EVN        Bologna  
Us      Ussuriisk, Russia  
Uu      Ulan-Ude, Russia             Defunct  
Uz      Usuda, Japan                 Tracking  
Wa      Wardle, UK                   Defunct  
Wb      Westerbork, Netherlands      EVN        Bologna  
   WB=Phased array  
Wf      Westford, USA  
Wh      Weilheim, Germany  
Wz      Wettzell, Germany  
Y       VLA, USA                                Socorra  
   Y=Phased array, Y1=Standard single ant. other stations = Y-arm-stn#  
Yb      Yebes, Spain                 EVN        Bologna  
Yk      Yellowknife, Canada  
Zc      Zelenchukskaya, Russia  
----------------------------------------------------------------  

A.2 Historical Notes

SCHED was written by R.C. Walker (RCW) in the late 1970’s for Mark II VLBI scheduling. It was part of the Caltech VLBI package. It received a number of modifications over the following decade by the author and others, including Tim Pearson, John Benson, and Mark Hodges. Beginning in 1988, the program was extensively revised by RCW to accommodate VLBA, and eventually global VLBI, scheduling. In 1991, a project to write VLBA OBSERVE was been begun by the NRAO with the programming being done by Wes Young. SCHED development was at a a minimal level during this development project as it was thought that the program would soon be retired.

In the Fall of 1995, the VLBA OBSERVE project was cancelled. An intensive effort was made then to add many of the features whose need had become apparent during the period of minimal development. In the Spring of 1996, Huib van Langevelde of JIVE, then stationed at NRAO, began work on the VEX additions which became a significant part of the program. Also, at about that time, Brian Butler provided the code needed to add the planet capability that is important for single dish pointing and gain measurements at high frequencies. Rick Lively provided systems support including writing makefiles and helping with interactions with users who were trying to install the programs on other machines. In January 1998, Franco Tinarelli of Bologna delivered the first code for point-and-click control of the SCHED plotting functions and has been supporting the plot functions ever since. In 2002, Cormac Reynolds took over support of the Vex portions of the code from Huib.

SCHED is currently the primary scheduling program used for astronomical VLBI. It is also capable of scheduling many types of observations on the VLA.

Appendix B
OBSOLETE SECTIONS

This chapter is a repository of documention of SCHED’s capabilities for systems that are no longer in use. It will not normally be of interest for current users. Much of what is here is details of handling tape.

B.1 Old VLA

Note that much of what is below applies to the old VLA system and has changed drastically with the EVLA upgrade. See the earlier section on VLBI at the VLA for more current information.

SCHED can be used to schedule essentially all types of VLBI observations on the VLA. It can also be used instead of OBSERVE to schedule pure VLA observations involving a limited subset of the special cards that can be in VLA schedules. This includes most continuum observations. This situation is likely to evolve as the EVLA upgrade, which includes a new control system, comes on line, so stay tuned. For more information on the VLA, check out the VLA from the NRAO home page at http://www.nrao.edu. For much detailed information on VLBI at the VLA, follow the links to VLBI at the VLA. The latter document is available in postscript form from the VLA home page.

All observations at the VLA need an observe file that is used by the VLA on-line computers to control the antennas and correlator. In addition, all VLBI observations at the VLA also require a VLBA-style control file for the VME that controls the VLBA data aquisition rack and recorder. SCHED produces both kinds of files.

The VLBA control file, called bq001crd.y by SCHED for an example project with EXPCODE=bq001, is similar to those provided for VLBA stations, except that some VLBA specific commands for receivers, etc. are omitted. This file controls BBC settings, when the recorder starts and stops, and other recording details.

The observe file, called bq001obs.y by SCHED in this example, is the file that is normally created by the NRAO program OBSERVE (can be found from the NRAO home page) and given to the VLA on-line system. While SCHED is intended for VLBI scheduling and this output is provided mainly for projects that use the VLA for VLBI, there is no reason that it cannot be used for scheduling pure VLA projects. In fact, a few parameters of interest only for non-VLBI projects are provided for VLA observers, including the ability to schedule in LST. However, SCHED has only limited ability to provide the special setup cards, namely those that start with “//”.

SCHED can provide “//LO” and “//FI” cards with parameters to set synthesizers to fixed values. The setup file can be used to provide values for the synthesizer settings. If FREQ or DOPPLER is used, the BBC settings will be adjusted to try to reach the right frequency for the VLBI data. Note that this has no effect on the VLA observing frequency. “//LO” and “//FI” cards are provided if, and only if, the required information is present in the setup file or could be obtained for the setup file by SCHED from the frequency catalog. SCHED also provides the “//PM” cards if proper (or planetary) motion is present for the source in the source catalog. Since the epoch of zero offset is given in IAT, IAT-UTC must be provided with parameter IATUTC in the SCHED keyin file. If other “//” cards are needed, or other options are needed on the “//LO” and “//FI’ cards, the regular VLA OBSERVE must be used or they must be edited in by hand. Beware of the fixed formats: if values are put in the wrong columns, the VLA on-line system will not behave as expected!

SCHED checks the ranges of the frequency settings given for the “//LO” cards. But the EVLA has made it possible to reach frequencies far outside the range of the original VLA hardware. Such frequencies can be requested using frequency settings in the style of the VLA, but outside the allowed VLA ranges. In addition, the parrameter EVLA should be given in the setup file to turn off some of the checks of frequency ranges. This is all at a primitive state as of Fall 2007 and will be updated as the EVLA matures.

B.1.1 VLBI at the VLA - old system

Note that many of the details of what is below applies to the old VLA system which is no longer in use.

For much detailed information on VLBI at the VLA, follow the links to the VLBI at the VLA guide.

There are two very different modes in which VLBI can be done at the VLA. These are single dish and phased array observations. For single dish VLBI observations, the IF signals from one antenna of the array are sent to the VLBI recording equipment (VLBA DAR and recorder). Other than having to worry about the VLA’s rather complicated LO system, such observations are very similar to observations at other VLBI observatories. The phased array observations, on the other hand, have some very special needs. For such observations, the signals from all VLA antennas are summed in the VLA correlator and the summed signal is sent to the VLBI equipment. This gives a sensitivity for the “antenna” that is increased by about the number of phased antennas, if the array is phased properly. Array phasing is accomplished by the on-line control system. Output phases from the correlator are used to derive adjustments to the phase of the LO at each antenna that, when applied, will cause the next correlator phases to go toward zero. The system can phase up on a calibrator and then freeze the phases on a target source when the target source is either too weak, resolved, or confused for successful phasing.

The type of VLA observation is distinguished by the VLAMODE. VLAMODE = VS indicates single dish observing. VLAMODE = VX indicates phased array observing, but using the phases from a previous phasing scan. VLAMODE = VA indicates phased array observing with phasing on the VLA A and D IFs and is the usual active phasing mode. VLAMODE = VB is similar, but with phasing on the VLA B and C IFs. VLAMODE = VR or VL indicates phased array observing using, respectively, the VLA A and B or C and D IFs. As might be deduced by this, because of hardware limitations, the VLA can only phase one of the A and C IFs and one of the B and D IFs. The VLAMODE can be changed on a scan-by-scan basis. See the description of the setup parameter IFCHAN for more information on routing VLA IFs to VLB IFs. VS mode (single dish) can be mixed with the phased array modes, but the number of changes back and forth should be limited. Normally this would only be done when atmospheric calibration, geodetic-like (DELZN) sections are included in a phase referencing project.

The reference antenna can be controlled with parameter VLARFANT. That will be the antenna from which data are recorded in single dish mode and the reference antenna (whose phases are not changed) for the phased array modes. Normally users should not worry about setting VLARFANT because the default is usually good, and if not, you will not know in time and the change needs to be made by operations.

For successful phasing of the array, a source must be greater than about 0.1 Jy (see the guide referenced above for details) and have a position that is good to a fraction of the VLA synthesized beam (enhanced sensitivity is only obtained over this area). It must have small structure phases and not have other sources in the primary beam that might confuse the phasing algorithm. The position accuracy is especially important if a calibrator is being used to phase the array for observations of another source. Adding phasing sources is tricky, because it is desirable to spend a minimum amount of time on them, but if they are missed, the rest of the data will be bad. It is possible to try to influence the speed of phasing by using VLAINTEG to adjust the correlator integration time. The default is 10 seconds. Use of a shorter time may speed phasing but is done at the expense of added noise.

There are two ways to deal with VLBI observations that require phasing on a source different from the target source. The best is probably to simply schedule VLBI scans, with the proper VLAMODE, on the phasing source. These observations can then also be used to assist the VLBI calibration, assuming an appropriate calibrator has been chosen. The other scheme is to insert calibration scans into the VLA’s schedule file (the OBSERVE file), but not the VLBI control file, for the phasing operation. SCHED provides some tools to simplify this operation. It can also be done using the VLA OBSERVE program. This is done by the VLA analysts for some programs.

For VLBI observations at the VLA, both an OBSERVE file and a VLBA style control file are needed and can be created by SCHED. All of the controls provided for managing recordings for the VLBA also work for the VLA. SCHED also has special capabilities for scheduling VLA observations as described below.

For observations that require phasing on a calibrator, the array must be phased in auto-phasing ( VLAMODE = VA) mode prior to VLBI observations of the target source in extended-phasing ( VLAMODE = VX) mode. These calibrator observations constitute additional scans that must be in the VLA observe file, but that no other VLBI observatory or the recorder control file for the VLA needs to know about. (Note that Westerbork needs something of the sort, but they have never requested special information in SCHED output files).

If it is desired to add phasing scans on a calibrator on which VLBI data will not be recorded and that will not be observed at the other VLBI observatories, the parameter VLAPSRC can be used. If a VLAPSRC is given, SCHED will automatically insert phasing observations in the VLA OBSERVE file at appropriate times. Note that VLAPSRC must be a source in the same catalogs that are searched for SOURCE and DOPSRC. SCHED will add a phasing scan to the observe file which will end either 1 minute before the main VLBI scan starts, or 3 minutes after the previous VLBI scan ends, whichever is later. If the latter option is used, SCHED complains if less than 2 minutes of the VLBI scan remains. Also with the latter option, the VLBA-style control file will still start the recorder when the main VLBI scan was supposed to start. This keeps recording at the VLA and other sites synchronized, although it can lead to the need to flag data that won’t have VLBI fringes. SCHED will not add a phasing scan if the VLBI scan is in VLAMODE=VA or if VLAPSRC is the same as SOURCE. This avoids the need to keep respecifying VLAPSRC whenever a VLBI calibrator is observed in mode VA and prevents the addition of unnecessary extra scans when the VLBI schedule calls for observations of the phasing source.

It is highly recommended that the NRAO OBSERVE program be used to check the VLA observe file for slew and dwell times on the phasing sources. The scan stop times may have to be adjusted with OBSERVE to obtain an adequate amount of on-source time for phasing. It is especially critical to be careful about slew times for sources near the zenith where long azimuth slews may be needed to go a short distance on the sky. SCHED only recently acquired to ability to calculate slew times and this has not yet been extended to the VLA phasing scans. This is an area of future construction.

SCHED is also able to deal with reference pointing using the PEAK command. Refer to the description of PEAK for details. The VLA-only example below uses this capability.

An Example

Below is an example of a file for a VLBI observation that uses the phased VLA. For phasing, a source is used that can also be used as a VLBI phase or fringe fitting reference. All antennas are sent to the reference and VLBI data is taken on it. This is now the prefered style for phasing. Of course the VLAPSRC parameter could also have been used if non-recording scans with only the VLA on the calibrator had been desired.

Note that the main example in the Examples section has a single VLA antenna in it and serves as an example of that type of observing.

B.1.2 VLA-Only Project Example

SCHED cannot be used for scheduling the EVLA (yet anyway) and the old VLA system has been turned off. So the following section is not of much use now. Once VLBI at the EVLA has been established, the capabilities to schedule EVLA runs with SCHED will be revisited.

This second VLA example demonstrates the use of SCHED to schedule a pure VLA project. The SCHED input for VLA observations is very much like that for VLBI observations. There are some parameters provided, and listed below, to control some of the input information for which the VLBI defaults may not be appropriate. The example is a modified version of an actual schedule used to make the VLA observations described. The modifications were required by changes in the way in which SCHED handles setup files and the parameters VLABAND, VLABW, PEAK, VLAMODE (for pointing scans), and VLAPEAK. Some of these parameters are now read from the setup files, not the main schedule input.

! -------------------------------------------------------------------  
! EXAMPLE setup file for non-VLBI observations at the VLA at 6cm.  
! -------------------------------------------------------------------  
!  vla-cc.set  
!  Non-VLBI observations at the VLA at C band  
format=none  station=VLA  vlaband=CC  vlabw=’0000’ /  
! -------------------------------------------------------------------

B.1.3 Parameters Specific to the VLA

The VLA capabilities in SCHED are for the old VLA system that has been shut down. Stay tuned for instructions related to running the EVLA (VLA).

This section gives a brief description of each of the parameters available to SCHED that are specifically for VLA observations or are especially useful for VLA observations. More general purpose SCHED parameters that are also required for other stations are not mentioned. For details on the parameters, consult the detailed descriptions of each parameter. The first list is of parameters in the main schedule input. The second is of setup parameters.

VLATYPE: Specify the type of observations. Should be provided for non-VLBI observations. Valid options are ’VLBI’, ’CONTINUUM’ or ’LINE’.

VLATSYS and VLANTSYS These turn on and off the Tsys corrections made to the correlated VLA data. This used to be required in order to obtain calibration data for the VLBI observations. That is no longer true so most observations can be made with the Tsys corrections turned on which is now the default.

VLAPEAK controls reference pointing on the VLA. It is a good idea to do reference pointing when observing at 7 mm. See the section on Reference Pointing to see how to get SCHED to insert reference pointing scans automatically.

VLAUSERN: This gives the VLA user number. The default of 600 is reasonable for VLBI but the actual user number should be provided for other types of projects.

VLAMODE: Specify the VLA mode. Common options for VLBI are , VA, VX, or VS. See VLA documentation on the many others that are available for non-VLBI observations.

LST: Schedule is assumed to be in LST. LST specified without a value assumes the VLA. A station name can be given as the argument, in which case the LST is for that station. When LST is specified, the DAY must be the modified local sidereal day number as found on VLA monthly schedules.

DAY: Must be the modified local sidereal day number as found on VLA monthly schedules if LST is specified. In such cases, YEAR and MONTH are ignored.

IATUTC: Difference between IAT and UTC, which is currently about 30 seconds. This is only used for setting the zero offset epoch for the “//PM” (proper motion) card.

SETUP: Specifies the setup file from which information for the “//LO” and “//FI” cards are taken.

FREQ: and DOPPLER Warning — these parameters cannot be used for non-VLBI observations at the VLA since they are only used to adjust the baseband converter frequencies.

RECord: and NORECord These parameters find one of their main uses in observations that use the VLA, especially the phased array. It is often useful, for both phasing scans and for scans inserted just for calibration of the VLA, to be able to turn the VLBI recorders off. RECord and NORECord can be used to specify which scans should be recorded on the VLBI drives and which should not be.

VLAPSRC: Phasing source to use before a VX mode scan. This is a convenient way to insert VLA phasing scans without having to explicitly include extra scans in a VLBI schedule.

VLARFANT: Reference antenna to use for single dish data source or as phasing reference for phased array. The default should be good, and, if not, operations is likely to need a last minute change, so it is unlikely that users should use this parameter.

VLAINTEG: This parameter gives the correlator integration time. It would normally be used to give a value less than 10 seconds to encourage faster phasing.

The parameters in the setup file that apply only to the VLA are below. They are used to set the band and bandwidths of the VLA and for setting up the “//FI” and “//LO” cards.

The values for all of these parameters, except FLUKESET, VLAIF, and VLAROT,, which are not normally needed, can be determined by SCHED from the frequency catalog. Therefore most projects do not require VLA specific parameters in the setup files.

The setup file parameters are:

FEFILTER: The front end filters are normally 50 MHz wide. If there is strong RFI near the observing frequency, as is common at L and P bands, it may be desirable to use the 25 MHz or 12.5 MHz front end filters. This parameter is used to request the filters to use. It goes on the “//LO” card.

FLUKESET: Which flukeset (1 or 2) to be used. Unfortunately there seems to be no good way to predict this reliably. Usually Flukeset 1 will be used for phased array and normal VLA observations while Flukeset 2 will be used for single antenna VLBI, but this is not always true. The VLA operators should be alerted that Flukeset specified on the “//FI” card might have to be changed. If it is not specified, or is set to 0, a blank will be given and the VLA operators will set it.

VLABAND: Specify the frequency band. Must be one of the defaults without the //LO and //FI cards. Some valid options are VP, VL, VC, VX, VK, PP, LL, CC, XX, UU, KK, HH, or 18. For complete information on the standard bands, see the following section.

VLABW: Specify the back end bandwidth for each of the 4 VLA IFs as a 4 digit number in quotes (SCHED treats it as a character string), with one digit for each IF. The default is ’0000’ for 50 MHz in each IF. The consequent back end bandwidth is 50/(2**n) MHz, where n is the digit specified.

FLUKEA: A Fluke synthesizer frequency. It is usually near 100 MHz. See the document “VLBI at the VLA” for details on what it should be. See Section 2.5 for more information on the frequency settings.

FLUKEB: B Fluke synthesizer frequency. Actually this is the value for the “//FI” card which is twice the actual synthesizer setting. To get the same frequency on the AC and BD IFs, FLUKEB should be FLUKEA plus 100.0.

VLAFEAB: 1st LO for the VLA observations for the AB (RCP) IFs. For standard VLBI projects, the value should be -3.2 for L band, 0 for C band, and 17.5 for K band. Again see VLA documentation for details of other alternatives.

VLAFECD: Same as VLAFEAB but for the VLA’s C and D (LCP) IFs.

VLASYNA: 2nd LO for the VLA A and C IFs. On the “//LO card” this number is rounded to the nearest MHz, but it should be given here exactly. It is usually near 3900 MHz. It must be a value of N * 50 +- 10.1 MHz.

VLASYNB: Same as VLASYNA but for the VLA B and D IFs.

B.1.4 VLA Standard Bands.

All of the below will change with the EVLA, which can reach just about any frequency. The following is basically obsolete.

A total of 19 standard observing bands are defined at the VLA. All projects should specify one of these bands, even when frequencies will be modified. This ensures that various defaults at the VLA get set properly. Just pick one with similar properties. For VLBI, one of the “V” bands should be chosen.

The tables below describe the bands. The first show the band names along with the synthesizer settings. The column headings are the SCHED names (not necessarily the traditional names in use at the VLA) for these parameters. The second table gives the value that SCHED would want for the VLBI FIRSTLO parameter when using the standard setup. If the frequencies are modified, FIRSTLO would need to be altered. SCHED will insure that FIRSTLO agrees with the frequency that will be obtained with the settings used. The other columns in the second table show the range of sky frequencies covered by the VLA band. The observing frequencies must lie in these bands. Note that the first frequency is that of the edge converted to DC, and then to 600 MHz in the signal sent to the VLBI rack. The other end of the band can be a lower frequency if there is a net lower sideband at this point (the BBC’s can be used in lower sideband mode to get a final net upper sideband).

The VLA band VQ will be changed a few months into 2001. The table below gives the frequencies for the new version. The old version was 80 MHz higher in frequency and missed the SiO line at 43.122 GHz. The current plan is to switch SCHED to the new VQ in January 2001, but have SCHED always write LO and IF cards in the VLA observe file for 43 GHz observing, even when using the standard band. After a few months in which any schedules made with the old scheme are flushed through the system, the VLA on-line system will be switch to the new standard. Some months after that, SCHED will stop writing the LO and IF cards for the new standard VQ band.

          VLA STANDARD BANDS - VLA SYNTHESIZER SETTINGS  
VLABAND  VLAFEAB  VLAFECD  VLASYNA   VLASYNB   FLUKEA     FLUKEB  FEFILT  
  CC      0.00      0.00    3860.1    3810.1  100.00000  200.00000  0000  
  UU     19.60     19.60    3610.1    3660.1  100.00000  200.00000  0000  
  KK     17.60     17.60    3860.1    3810.1  100.00000  200.00000  0000  
  LL     -3.20     -3.20    3639.9    3560.1  100.00000  200.00000  0000  
  XX     13.40     13.40    3939.9    3889.9  100.00000  200.00000  0000  
  QQ     51.60     13.00    3689.9    3739.9  100.00000  200.00000  0000  
  PP      0.00      0.00    -689.9    -710.1  115.83750  230.10000  1111  
  44      0.00      0.00    -939.9    -939.9  112.91875  212.91875  0000  
  4P      0.00      0.00    -939.9    -689.9  112.91875  215.83750  1111  
  LP     -3.20      0.00    3639.9    -689.9  100.00000  215.83750  0101  
  18     -3.20     -3.20    3839.9    3810.1  100.00000  200.00000  0000  
  HH     -3.20     -3.20    3589.9    3639.9  115.10000  215.10000  0000  
  VP      0.00      0.00    -689.9    -689.9  112.50000  212.50000  1111  
  VL     -3.20     -3.20    3839.9    3839.9  100.00000  200.00000  0000  
  VC      0.00      0.00    3960.1    3960.1  100.00000  200.00000  0000  
  VX     13.00     13.00    3560.1    3560.1  100.00000  200.00000  0000  
  VU     19.90     19.90    3510.1    3510.1  100.00000  200.00000  0000  
  VK     17.50     17.50    3710.1    3710.1  100.00000  200.00000  0000  
  VQ     51.60     13.00    3510.1    3510.1  100.00000  200.00000  0000  
 
          VLA STANDARD BANDS - VLBI FIRSTLO and VLA BANDPASSES  
VLABAND FIRSTLO A  FIRSTLO D         BANDPASS A           BANDPASS D  
  CC     4260.10     4210.10     4860.10-  4910.10    4810.10-  4860.10  
  UU    15589.90    15539.90    14989.90- 14939.90   14939.90- 14889.90  
  KK    21860.10    21810.10    22460.10- 22510.10   22410.10- 22460.10  
  LL      839.90      760.10     1439.90-  1489.90    1360.10-  1410.10  
  XX     9060.10     9110.10     8460.10-  8410.10    8510.10-  8460.10  
  QQ    42689.90    42739.90    43289.90- 43339.90   43339.90- 43389.90  
  PP  -274.06250     -280.00   325.93750-350.93750     320.00-   345.00  
  44  -526.98125  -526.98125    73.01875-123.01875   73.01875-123.01875  
  4P  -526.98125  -274.06250    73.01875- 98.01875  325.93750-350.93750  
  LP      839.90  -274.06250     1439.90-  1489.90  325.93750-350.93750  
  18     1039.90     1010.10     1639.90-  1689.90    1610.10-  1660.10  
  HH      805.00      855.00     1405.00-  1455.00    1455.00-  1505.00  
  VP     -277.40     -277.40      322.60-   347.60     322.60-   347.60  
  VL     1039.90     1039.90     1639.90-  1689.90    1639.90-  1689.90  
  VC     4360.10     4360.10     4960.10-  5010.10    4960.10-  5010.10  
  VX     9039.90     9039.90     8439.90-  8389.90    8439.90-  8389.90  
  VU    15989.90    15989.90    15389.90- 15339.90   15389.90- 15339.90  
  VK    21610.10    21610.10    22210.10- 22260.10   22210.10- 22260.10  
  VQ    42510.10    42510.10    43110.10- 43160.10   43110.10- 43160.10  
 Note that IF A and C are usually at the same frequency as are B and D.  

B.2 Tape Management

B.2.1 GENERAL CONCERNS

A fact of life with VLBI has been that the data are recorded on tapes and tapes have various limitations. Tapes are not infinitely long and they cannot be stopped and started instantaneously. Whenever they are stopped, they must be resynchronized at the correlator, which takes a few to a few tens of seconds. Also tapes have finite bandwidth and capacity. The instantaneous bandwidth cannot be exceeded. This section provides some detail on various aspects of tape management.

Many of the concerns described here do not apply to the disk based recording systems (mainly Mark5) that began to be deployed in 2003. The disk systems can start and stop very quickly and take less time to be synchronized on the correlators. There still are limitations on the total bit rate and recording volume. But disk management is be much less visible to the user than tape management. For the rest of this section, we are talking about tapes. Hopefully by late 2005, this whole section can be relegated to a historical appendix to this manual.

The scheduler always has to worry about not exceeding the amount of tape that has been allocated for the project. For projects only including stations that use automatic tape allocation (eg VLBA, VLA, and GBT), that should be the only concern other than providing occasional gaps for readback tests, as described later, and not stopping the tape too often. Automatic tape handling is described in more detail below in the section on automatic tape allocation and in the description of the AUTOTAPE input parameter. If there are any stations at which automatic tape handling is not being used, the scheduler has a lot more to worry about. Tape reversals, without automatic tape handling, can only occur at scan boundaries. For efficient tape usage, the schedule must have scan breaks at appropriate intervals given the tape type and recording speed. More is said about this below, especially in the section on tape lengths.

The schedules sent to the antennas will also have to specify such details as track assignments, head positions etc unless automatic tape allocation is used. The user, however, should not need to worry about these details since SCHED has defaults that work fine in all but odd test observations. For the masochistic, the details of the SCHED defaults are given in Appendix B.5.

The maximum bit rate that can be recorded on a VLBA tape is 256 Mbps. The systems at the VLBA antennas and at the VLA and Green Bank have two drives and can use both simultaneously to achieve 512 Mbps. Mark IV systems can have 2 head stacks on a single drive to achieve 512 Mbps. In addition, they can record at 16 Mbps per track, twice the normal maximum rate. With both heads recording at 16 Mbps per track, the Mark IV systems can reach 1024 Mbps.

When part of an project uses the two drive (VLBA) or two head (Mark IV) mode, all of that project will be recorded in that mode. If some scans use narrower bandwidth, the tape drives will be slowed. This avoids lots of confusion in keeping track of tape usage.

B.2.2 TAPE HANDLING at SCAN BOUNDARIES

There are a number of concerns related to tape handling at scan boundaries. SCHED provides a variety of ways to specify what is to be done. Between scans, tapes can be kept running or can be stopped. If they are stopped, they can be started at the nominal start time, or at some other time, usually earlier. The actions taken can strongly influence how well correlation proceeds. Whenever a tape is stopped, there is some time lost to resynchronize on the correlator. Also, with short segments of tape motions, it is possible for the VLBA correlator to wind up sufficiently far out of sync that it does not recover until either the end of the pass or the end of the correlator job. Basically, if the schedule consists of long scans, it doesn’t really matter much what is done. But if it has many short scans, such as when phase referencing, it can be highly advantageous to keep the tape moving between scans.

Obviously, tapes must be stopped at the ends of passes so that their direction of recording can change. They also must stop when they are changed. If there are long gaps (many minutes) between scans, tape use efficiency is enhanced if the tapes are stopped. If automatic tape handling is being used (normally true at the VLBA and VLA, but not elsewhere), tape stoppage at pass and tape ends will happen automatically and the user need not worry about them. The user should, however, provide occasional tape stoppages of at least 2 minutes (4 min in VLBA 512 Mbps mode) to allow for readback tests. These need not be at the ends of passes.

As the gap between scans gets shorter, or the scans become more frequent, it becomes advantageous to keep the tapes rolling between scans, assuming that the correlator does not require that they stop (the older Mark III system had such a requirement). One way to do this is to use DURation rather than DWELL to specify scan times and not give any command such as GAP that will cause an interval to be scheduled between scans. This simply butts the scans together. If there are gaps between the scans, such as when DWELL or GAP are used, the default behavior of SCHED will automatically keep the tape running if the gap is less than 8 seconds times the speed up factor (usually 2). That interval can be adjusted with the parameter MINPAUSE.

One can request, preferably with parameter PRESTART, that recordings be started before the nominal start of a scan. This can cause the recording medium to keep moving if the gap is short. For longer gaps, it can help optimize the amount of correlator output by providing time for the correlator to synchronize.

B.2.3 TAPE LENGTHS and PASS TIMES

Tapes for the Mark III and VLBA systems come in two nominal lengths, 9600 ft and 18000 ft. Actually, nearly all of the shorter tapes have now been removed from the system so most users will not encounter them. The lengths vary plus the usable length is shortened by the amount of leader needed at each reel. Experience has shown that it is best not to count on more than 17600 feet for the long “thin” tapes. Most short “thick” tapes are over 9000 feet, but there are a significant number as short as 8500. It is probably reasonable to assume that the short tapes will be 8800 ft, half the length of the long tapes, for scheduling purposes.

There are three basic recording speeds to consider, at least when using the VLBA correlator. The “normal” speed it that at which 4 million data bits per second are recorded on each track. Mark III and Mark IV format data at low density are recorded at 135 ips (inches per second). VLBA format data at low density are recorded at 133.33 ips. All formats at high density are recorded at 80 ips, which is now the standard for most observations. Recording rates of half and twice these values are used when the number of bits per second per track is half or twice the 4 Mbps. High density recordings can only be made on “thin” tapes. The VLBA correlator plays back all observations at a track bit rate of 8 Mbps, using 160 ips for high density recordings. Thus there is a speed up factor for recordings made at lower speeds — a factor of 2 for 4 Mbps tracks and a factor of 4 for 2 Mbps tracks.

The following table gives the recording times per pass to expect with these tape speeds and recording rates:

 ------------------------------------------------------------------  
     RECORDING TIMES for 1 pass on VLBA and Mark III tapes.  
 ------------------------------------------------------------------  
     Tape length   Format /        Bit rate per track  
        (feet)      density     (2 Mbps)   (4 Mbps)   (8 Mbps)  
 ------------------------------------------------------------------  
        17600      All/High     1:28:00      44:00      22:00  
        17600      VLBA/Low       52:48      26:24      13:12  
        17600      Mark III/IV    52:08      26:04      13:02  
         8800      VLBA/Low       26:24      13:12       6:36  
         8800      Mark III/IV    26:04      13:02       6:31  
 ------------------------------------------------------------------

When full automatic tape handling is not being used, scans should be scheduled so that they are in blocks that constitute a pass. This is not absolutely necessary, because, regardless of the scan times, SCHED will make sure that the scan will fit on the tape and, if not, will reverse the tape. If a scan cannot fit, SCHED will complain and die. Because of these actions, no data will be lost if the schedule is not in blocks of a tape pass, but some amount of tape will be wasted — it is better to be aware of the pass lengths. In fact, it is not uncommon for a user to find that, when he/she deletes a scan, the amount of tape used increases. This happens when a schedule that went to the end of tape on each pass gets out-of-sync and has to reverse the tape before the end. Once this starts to happen, it often continues for the rest of the experiment. Note that it is typical to round down the pass times to, for example, 13 minutes for those cases where the full number is 13:02 or 13:13.

Scheduling in blocks of tape passes is more complicated if there is a mixture of thin, high density tape at some sites and thick, low density tapes at other sites. For Mark III, the longer tapes will hold 3.37 times as much data per pass as the shorter tapes. Probably the best way to deal with this is to schedule in blocks such that the 2 blocks fit per pass on the thick tapes and 7 blocks fit on the high density, thin tapes. The appropriate time for this for Mark III or VLBA formats is 6:17. Be careful with scans less than 30 seconds in such a schedule because the passes could get out of sync. Mixed thick and thin tape observations should be rare, especially since the VLBA correlator refuses to deal with thick tapes.

Note that, if there is a problem at a station and a tape does not start on time, or a scan is missed, the tape position will be behind that expected by SCHED. At the end of the pass, the tape will reverse when the schedule tells it to, which in this case will be some distance from the end. For this reason, the next pass is likely to run out of tape before it is finished and some data will be lost. The pass after that will begin at the expected place and there will be no further problems.

Users of PCFS controled stations (eg EVN) should be aware that during long scans no Tsys information is acquired. It is necessary to insert gaps to make sure Tsys measurements are made.

B.2.4 NUMBER of PASSES

The amount of data that can fit on a tape depends on the length of the tape, the tape speed, and on the number of passes. The Mark III and VLBA systems make longitudinal recordings using many heads, all mounted on a head stack. The width of each head is 38 microns and the “head pitch”, or spacing between heads, is 698.5 microns. This difference allows many passes to be recorded with each head simply by shifting the whole head stack over by something more than 38 microns between passes (48 microns is used on the VLBA). The Mark III systems typically use 12 passes while the VLBA and Mark IV use 14.

Many recording modes do not use all of the heads at once. Mark III systems use 28 heads while VLBA and Mark IV systems use 32 (they all actually use the same 36 head headstack so the head pitch etc is the same). Mark III Mode A uses all heads in a pass. Modes B and C use half the heads while Mode E uses a quarter. There are many VLBA modes, but they typically use a quarter, half, or all heads, although lesser options are available. If not all the heads are used in a pass, more passes can be made at the same head position, increasing the total time over which data can be recorded on tape. The setup file parameter TPMODE gives the number of passes that can be recorded at each head position. SCHED will figure it out if it is not given and will report it in the summary.

If multiple setups are used in a project, SCHED will figure out which uses the minimum number passes per head position (most tracks per pass) and will use that number of passes per head position for all setups. This wastes tape because some tracks never get recorded, but the alternative is a bookkeeping mess. Therefore, it is strongly recommended that all setups used in a project use the same number of heads per pass (have the same TPMODE).

It is perfectly possible to use setups that record at different speeds in the same schedule. As long as they all use the same number of heads, the tape will be used efficiently. However, a change of recording speed causes the VLBA correlator to need a new job. This is not a fundamental problem, but there is overhead for each job which causes work for the correlator staff. Current guidelines on how often changes of this sort can be made can be found in the guidelines for scheduling document found by going to the VLBA home page from the NRAO home page on the WWW. As of late 1996, changes more often than every 2 hours are discouraged. Note that using different tape speeds in different subarrays at the same time will preclude simultaneous correlation and will present the current job script making program with bookkeeping problems it is not equipped to handle. Don’t do it!

The total time that can be recorded on a tape is the time per pass times the number of passes per head position times the number of head positions. The following table gives the total time per tape, and also the total bit rate, for various combinations of these parameters.

 ------------------------------------------------------------------  
     TOTAL RECORDING TIMES per TAPE  
 ------------------------------------------------------------------  
  Pass/head   Heads     Track bit   Passes  Tape time  Total bit  
   position  recording  rate (Mbps)                   rate (Mbps)  
 ------------------------------------------------------------------  
       1        1           2         14     20:32:00      64  
       1        1           4         14     10:16:00     128  
       1        1           8         14      5:08:00     256  
       1        2           8         12      4:24:00     512  
       1        2          16         12      2:12:00    1024  
       2        1           2         28     41:04:00      32  
       2        1           4         28     20:32:00      64  
       2        1           8         28     10:16:00     128  
       4        1           2         56     82:08:00      16  
       4        1           4         56     41:04:00      32  
       4        1           8         56     20:32:00      64  
 ------------------------------------------------------------------  
   All tapes are assumed to be 17600 ft long.  
   All recordings are assumed to be done at high density.  
   Modes with 2 heads are MarkIV only.  
   VLBA uses 2 drives at 256 Mbps each for 512 Mbps.  
 ------------------------------------------------------------------  

For mostly historical interest, below is the old version of the table which includes the tape times for the low density and/or thick tapes. The 512 and 1024 Mbps modes were not available at the time.

 ------------------------------------------------------------------  
     TOTAL RECORDING TIMES per TAPE (14 Head positions, 32 Heads) *  
 ------------------------------------------------------------------  
  Tape length   Format/den  
  Bit rate per track  
     (feet)                  (2 Mbps)   (4 Mbps)   (8 Mbps)  
 ------------------------------------------------------------------  
  1 Pass/head pos.  Bit rate: 64 Mbps   128 Mbps   256 Mbps  
     17600      All/High     20:32:00   10:16:00    5:08:00  
     17600      VLBA/Low     12:19:12    6:09:36    3:04:48  
     17600  Mark III/IV/Low  12:09:52    6:04:56    3:02:28  
      8800      VLBA/Low      6:09:36    3:04:48    1:32:24  
      8800  Mark III/IV/Low   6:04:56    3:02:28    1:31:14  
 
  2 Pass/head pos.  Bit rate: 32 Mbps    64 Mbps   128 Mbps  
     17600      All/High     41:04:00   20:32:00   10:16:00  
     17600      VLBA/Low     24:38:24   12:19:12    6:09:36  
     17600  Mark III/IV/Low  24:19:44   12:09:52    6:04:56  
      8800      VLBA/Low     12:19:12    6:09:36    3:04:48  
      8800  Mark III/IV/Low  12:09:52    6:04:56    3:02:28  
 
  4 Pass/head pos.  Bit rate: 16 Mbps    32 Mbps    64 Mbps  
     17600      All/High     82:08:00   41:04:00   20:32:00  
     17600      VLBA/Low     49:16:48   24:38:24   12:19:12  
     17600  Mark III/IV/Low  48:39:28   24:19:44   12:09:52  
      8800      VLBA/Low     24:38:24   12:19:12    6:09:36  
      8800  Mark III/IV/Low  24:19:44   12:09:52    6:04:56  
 
 ------------------------------------------------------------------  
 *  Systems with Mark III hardware use 28 heads and 12 head positions  
    so the recording times are lower.  

If the tape allocated is insufficient to record for the whole allocated time at the desired bit rate, there are several options. The most common is to use a duty factor of less than one — to stop the tape for some of the time. Otherwise, it is necessary to cut down the bit rate or to request more tapes (good luck). Some periods of stopped tapes are desirable for readback tests.

B.2.5 READBACK TESTS

One way in which the performance of the recording system is monitored is to read back some data from the tapes and check the playback quality. On the VLBA and Mark IV systems, this is done any time there is a gap of longer than about 2 minutes per tape (actually somewhat less). If a really bad head is found, it is possible to make a copy of the data from that head on one of the system tracks (recall that the headstacks have 36 heads). Some day, the correlator will be able to use this data, although not yet. On the VLBA, where there are two tape drives available, it may be possible to switch to the other drive to avoid the problem. It is in the interests of both the individual project and of overall system maintenance for occasional gaps to be inserted in all projects for readback tests to be done. These gaps are often inserted at the ends of passes when automatic tape allocation is not being used.

Readback tests on the VLBA systems cannot be done on both drives at once so, when using the 2 tape, 512 Mbps mode, a gap of a bit less than 4 minutes will be required to complete a set of tests.

SCHED will look for gaps long enough for readback tests. It will report the number for each station in the summary file. If there are less than one every 2 hours, it will complain, but go ahead and make schedules anyway.

B.2.6 TAPE CHANGES

If a project is being scheduled that uses stations that have only one tape drive, it is necessary to schedule in a gap of about 15 minutes for that tape change to be accomplished. Some stations can do it faster, but it is best not to count on it. The VLBA stations and the VLA all have 2 tape drives each and the project will switch from one to the other when the first runs out. Then the operators can change the full tape at their leisure. For these stations, it is not necessary to schedule tape change times. SCHED will complain, but not die, if a single tape station is requested to change tapes in less than 15 minutes. The SCHED input parameter TAPE is used to force tape changes. It can take station names as arguments if you only want to change tapes at a subset of stations.

An additional concern is that postpasses are needed for thin tapes. This can consume up to 22 minutes. See the beginning of this section for more details.

Sometimes it is a good idea to synchronize tape changes at at least some of the sites. For example, at least in late 1996, the VLBA correlator will not process the time between tape changes at different sites if they are less than something like 3 minutes apart. For optimized schedules, this can present a bit of a problem, so the input parameter TAPESYNC is provided to try to cause all stations that are near the end of their tape to change when the first reaches the end. With automatic tape allocation, the user does not have control of this factor and should not worry about it, although it might cause some loss of data.

B.2.7 POSTPASSES

It is now considered necessary to postpass VLBA/MarkIV thin tapes after recording. This means winding the tape all the way to the end and back to the beginning without stopping. This avoids irregularities in the tape pack that could otherwise lead to tape damage in handling and shipping. These irregularities are caused by starts and stops. Since tapes cost over $1000 each, this is a serious issue. SCHED will give the necessary commands to request postpasses be done at stations that use VLBA control files.

Unfortunately, a postpass takes between 11 and 22 minutes depending on how far the the tape has to be fast-forwarded to reach the end. This is down from a maximum of 33 minutes prior to late 1997 when it was determined that rewind speed could be used. For two tape stations, this is not a problem. For single tape stations, it is can be serious since it adds this much to the tape change time. Also, if there is an inadequate gap in the schedule, the next tape can be out of the expected position on the first pass which can cause additional losses when the first reverse pass runs out of tape early. SCHED provides a way to avoid postpasses by keeping track of tape motions. If the last pass went from the far end of the tape to the beginning without stopping, a postpass is not required and is not requested by SCHED. Therefore, users with single tape stations (all except the VLBA and VLA) who are using more than 1 thin tape per station are advised to not stop the tape on the last pass before each tape change.

B.2.8 AUTOMATIC TAPE ALLOCATION

Automatic tape allocation is provided on the VLBA. In fact, its use is required for most observations. With automatic tape allocation, the only thing the user needs or can worry about is the total tape consumption. It much be kept below that allocated for the experiment. There are two reasons for the use of automatic tape allocation. The first is to relieve the user of all the worry about tape handling. It is no longer necessary to schedule everything in units of passes. The second is to decouple the tape change times from the times allocated to each project. This allows the tape changes at the stations to be done on a fixed schedule that is the same every week and which fits well with the work schedule for the site techs. This does cause tapes to contain data from more than one project, but the bookkeeping is in place to insure that they don’t get erased until all the projects are correlated. Recall that the VLBA stations are unmanned most of the time. The second reason is why the use of automatic allocation is required.

Automatic tape allocation is not available for all stations, including all that use VEX files. SCHED knows which stations can use it and schedules accordingly. For global observations to be correlated on the VLBA correlator, the scheduler needs to worry about tape handling at the stations without auto allocation, but can ignore it for the ones that have it. For any observations to be correlated on other correlators (including JIVE), automatic tape allocation cannot be used and SCHED will not allow it.

Two levels of automatic tape handling are available on the VLBA. They are invoked using the parameter AUTOTAPE. The lower level allows the on-line system to decide where on the tape to start the next scan. However if the scan runs out of tape going in the current direction, the recorder will stop and the rest of the scan will be lost. After the first forward pass, any scan starting less than 450 feet from the end of the tape will be started in the opposite direction. The first forward pass always runs to the low tape sense to determine the tape length. It is the author’s opinion that, because of the variable length of tapes, projects scheduled with this scheme are very likely to exhibit unexpected behavior with possible considerable loss of data. It should work ok for long scans that intentionally try to drive well beyond the end of the tape, but this is almost worse than worrying about specifying the tape behavior at schedule time. This level of automation is not recommended.

The higher level of automation is the method of choice for tape scheduling. It would be even better if the speed of synchronization on the correlator were improved, but that project doesn’t seem to be getting any priority. With this mode, whenever the tape gets to an end, it stops and reverses. The minimum time lost is the time required to reverse the tape at the correlator, which is about 5 seconds times the speed up factor. However some time to resync after the reversal is required and the actual time is more like 10 seconds times the speed up factor and somewhat variable. For most experiments the data loss should not be a significant problem. Scans of arbitrary length can be scheduled. The user only need to worry about not exceeding his/her total tape allotment. The total amount of tape used in a schedule is reported in the summary file. Note that the same behavior, where scans starting within 450 feet of the expected end of tape after the first pass will start in the opposite direction, also applies with this level of automation. 450 feet is 67.5 seconds at 80ips — the speed that gives a speed up factor of 2 on the VLBA and is used by a large fraction of observations.

When automatic tape handling is requested, as is required for most VLBA projects, it is futile to worry about coordinating scans with tape passes. Don’t bother to try. There are two reasons for this. First, the tape position at the start of the project will depend on where it was left by the previous project. It will not necessarily be at an end. Second, the autoallocation software uses the real length of the tape as measured on the first pass. Tapes vary in length by several hundred feet depending on their history of abuse. So you cannot know ahead of time where a scan will be on the tape so there is no point in trying to schedule passes unless some antennas in the array are not using autoallocation.

If a station that is using automatic tape allocation is scheduled in a scan on a source that is below the antenna hardware limits (not just the horizon), that antenna will be removed from the scan by SCHED. This will not happen when or where automatic allocation is not in use because the tape management could be messed up. This action is provided mainly to help the Mauna Kea site technicians who have a very long drive to change tapes and whose antenna is often scheduled in scans for which the source has not yet risen. Mark5 stations that are not using tape will also be scheduled in this manner. This behavior can be overridden using DODOWN

B.3 Mark III Observations

To schedule Mark III projects using non-VLBA control file stations or a Mark III correlator, it is best to use PC-SCHED, written by Alan Rogers and Dave Schultz at Haystack (unrelated to SCHED), or SKED, written by Nancy Vandenberg at Goddard Space Flight Center. PC-SCHED can read a very basic SCHED keyin file to get scan times and generate Mark III schedules. This is mainly useful to help get the files needed by a Mark III correlator to process a Mark III observation on the VLBA that was scheduled with SCHED. PC-SCHED and SKED produce a “Standard Schedule File Format” file, which is also known as the “sked file”, “.vex file”, “.drg file”, or “drudg file”. This single file contains a complete description of the experiment for all stations.

There is a program called DRUDG, associated with the Mark III systems, that is used to convert the “.drg file” into snap files to control the antennas and tape systems. DRUDG can produce VLBA control files and is used to do so regularily by the geodetic groups. It is rarely used to make schedules for non-geodetic projects. PC-SCHED also is able to produce VLBA control files, but this capability has not been kept up-to-date and should not be used.

An NRAO program called SKEDCONV exists to convert “.drg files” files into SCHED keyin files. It is recommended that most VLBA Mark III observers send their “.drg files” files to the AOC, where the staff will use SKEDCONV and SCHED, along with current setup files, to make the VLBA control files. Instructions on how to submit schedules are provided to observers when they are allocated observing time.

There are no definite plans to support Mark III observations fully with SCHED because the system will soon be obsolete. It will be replaced by the Mark IV system, which is basically an upgrade that uses the same tape recorders (upgraded) and heads, but a new formatter and wider bandwidths from the video converters. SCHED supports the Mark IV system through the VEX control files. However, as mentioned elsewhere, the Japanese systems related to VSOP have been designed around the “.drg file”. Hooks have been provided in SCHED where they can attach routines to write “.drg file” output. If this project is completed, SCHED may acquire at limited Mark III capability.

Mark III observations on stations that use VLBA control files (VLBA, VLA, and Green Bank) can be scheduled directly with SCHED. The only difference between Mark III and VLBA format projects on these antennas is the data format on the tape (see the setup file input FORMAT) and various details in the setup files. Mark III observations have a one-to-one correspondence between tracks and channels, use one bit samples, and do not barrel roll. They typically use 7 or 14 channels, although Mark III format can be used on any project with no fan out. Anyone scheduling Mark III observations should either use standard setup files or, if making their own, should start with a standard file as a template. Such observations can be correlated on the VLBA correlator, but require production of a “.drg file” if sent to a Mark III correlator.

The PCFS can control Mark III observations on Mark III, Mark IV, and VLBA hardware. However, it will only do this with a Mark III type “.drg file” for input. Since SCHED does not produce such files, it cannot currently schedule Mark III format observations on systems that do not use the VLBA control files (e.g. the EVN). The “.drg file” is also required to control Mark III correlators, and therefore SCHED cannot be used to control experiments that are destinated for such correlators without causing considerable extra effort to generate such a file later. A possible future upgrade to the PCFS and SCHED would allow the use of VEX files to control observations on Mark III hardware or configure Mark III modes on Mark IV hardware.

The VLBA correlator is capable of correlating VLBA, Mark IV, and Mark III formats against each other as long as the sample rates and recording speeds were the same. Therefore the VLBA and Mark IV stations of a global observation that also involves Mark III stations could be scheduled with SCHED if it were to be processed in Socorro. Of course, the Mark III stations would still have to be scheduled somehow, so one of the other programs would probably be used anyway.

B.4 Scheduling Mark II Observations

SCHED was originally written in about 1978 as the Caltech Package scheduling program for Mark II VLBI. Most Mark II observations done since then were scheduled with it. But the program is outlasting the system that it was designed to support. I began the process of removing Mark II from SCHED when I learned that it is still in use in some parts of the world. Therefore, it is being retained for now.

Mark II recording systems have been removed from most active VLBI stations and the main Mark II correlators are no longer operating. However, the system is not completely gone. An old Caltech correlator is being supported at Medicina and Mark II recording systems are being supported at a few places. For these reasons, the Mark II specific features of SCHED have not yet been removed.

Mark II observations typically use one of the Mark III or VLBA data aquisition system baseband converters (called video converters in the Mark III world). Therefore much of the setup information required for the wide band systems is also required for Mark II, although only for a single channel. A very few parameters are available that are only for Mark II and the descriptions of those parameters should be consulted. In the main program input, the only such parameter is TPREF which helps get the tape changes synchronized. In the tape initialization parameters, parameter TPTIME serves a similar purpose. The main schedule parameter AUTOTAPE has special meaning for Mark II observations. Other than these special cases, the parameters used for a Mark II project are essentially the same as for a wide band experiment. Of course, parameters related to control of the wide band tape systems are not needed.

Tape management for Mark II observations is simpler than for wide band observations. Normally the tapes are run continuously for 4 hours per tape and then changed, usually by hand. Correlator operators normally prefer is all tapes are changed at the same time, which can be arranged using TPREF or TPTIME. The schedule should have scan breaks at the tape change times (this will be forced by SCHED, so tape changes might be requested at odd times if scan breaks don’t occur at the nominal 4 hour intervals.

Below is an example of a simple Mark II schedule. Be warned that this aspect of SCHED is not being maintained because Mark 2 is no longer available at most stations. Also, this example is not being tested with each release.

 SIMPLE EXAMPLE  
 --------------------------------------------------------------------  
     !   Cover information:  
 EXPT = ’Mark II, 3C345, May 1986’  ! Any description.  
 EXPCODE = ’C85G’                   ! Project code.  
 VERSION = 1                        ! Version 1 of schedule  
 PINAME = ’Craig Walker’            ! Principal Investigator’s name.  
 ADDRESS1 = ’National Radio Astronomy Observatory’  ! Address  
 ADDRESS2 = ’P. O. Box O’                           ! Up to 4 lines.  
 ADDRESS3 = ’Socorro, New Mexico, 87801’  
 ADDRESS4 = ’ U.S.A. ’  
 PHONE    = ’505 835 7247 ’         ! Telephone number  
 OBSPHONE = ’505 835 7247 ’         ! Phone number during observations.  
 EMAIL    = ’Internet: cwalker@nrao.edu’   ! Electronic mail address.  
 FAX      = ’505 835 7027 ’         ! Phone number for FAX.  
 TELEX    = ’910-988-1710 ’         ! Telex number.  
 OBSMODE  = ’6cm  Mark~II Standard Setup’  ! Observing mode.  
 CORREL   = ’Caltech’               ! Correlator to ship tapes to.  
 NOTE1    = ’You can put any comments you want to in these four lines.’  
 NOTE2    = ’ More comments ’  
 NOTE3    = ’ More comments ’  
 NOTE4    = ’ Last of the comments’  
 
 !         Now the actual schedule information.  
 SRCFILE = sources.obs              ! Source catalog.  
 STAFILE = stations.dat             ! Station catalog.  
 SETUP   = nug6cm.set               ! Setup file.  
 YEAR = 1986  MONTH=5  DAY=11       ! Date of first stop time.  
 STATIONS=BONN,BOLOGNA,HSTK,NRAO,  
          VLA,VLBA_PT,OVRO          ! Stations list  
 VLAMODE=’VS’                       ! Required information for VLA  
 START = 02:00:00                   ! Start time in UT.  
 TPREF = 1::                        ! Control tape change times.  
 SOURCE = ’3C345’                   ! Source name.  
 DUR = 30:00   REP = 8              ! 8 scans of 30 minutes each  
 /                                  ! End of first group of scans.  
 SOURCE=’NRAO512’  DUR=30:00  /     ! One scan on another source.  
 SOURCE=’3C345’  DUR=30:00 REP 9 /  ! 9 more scans on main source.  
 --------------------------------------------------------------------  

Below is an example setup file for Mark II observations. This is the standard setup file nug6cm.set and contains the correct information for the VLBA and VLA, which no longer have Mark II recording equipment. For a real Mark II observations, the stations involved would have to be added.

---------------------------------------------------------------------  
 EXAMPLE:   Setup file for Mark~II observations (1 channel) at 6cm.  
 --------------------------------------------------------------------  
! nug6cm.set  
!      Setup file produced by MAKESETUP.  
!      Modifications will be lost next time MAKESETUP is run.  
 
nchan = 1  bbfilter = 2.0 format = MARKII  
bbc = 1 netside = U  
ifchan = L  
!    Radio Astronomy allocation: 4990-5000  
!    Radio Astnomomy footnote:   4950-4990  
!    VLA 50MHz 4960.1 to 5010.1 with VC mode.  
!        VLA 6cm receiver falling off at high end.  
freqref  = 4990.99  !  Mark II network standard.  
fe(1) = ’6cm’   fe(3) = ’6cm’   synth(2) = 4.1  
firstlo  = 4100.00  
station  = VLBA   rchan = A  lchan = C   /  
firstlo  = 4360.10  
station  = VLA1   rchan = B  lchan = D   /  
station  = VLA27  rchan = A  lchan = C   /  
firstlo  = 4260.0  
station  = GB_VLBA  rchan = A  lchan = C  /  
station = ’EB_VLBA’  
fe(1)=’6cm’ fe(3)=’6cm’  
firstlo = 4100.0  rchan=A lchan=C  /  
 

END OF OLD TEXT.

B.5 Head Positions and Track Assignments

This appendix describes the default track and head assignments used on the VLBA for projects scheduled using SCHED. These are gory details that most users should not need to be concerned about. Just let SCHED use its defaults and the observations should be ok.

The VLBA uses 14 head positions. Both the positions and the order in which they are used are the same for all projects. The head position for each index number are in the following table in microns.

             HEAD POSITIONS  
--------------------------------------------  
     Forward Passes      Reverse Passes  
     Index   Offset      Index   Offset  
--------------------------------------------  
       1     -319          2       31  
       3     -271          4       79  
       5     -223          6      127  
       7     -175          8      175  
       9     -127         10      223  
      11      -79         12      271  
      13      -31         14      319  
-------------------------------------------

All forward passes are to be written in the negative offset positions and all reverse passes are to be written in the positive offset passes. This ensures that nearly all adjacent tracks are in the same direction and minimizes the required guard bands.

The following tables give the head index position and the and the set of heads that are used for each pass for experiments using 1, 2, 4, and 8 passes per head position: Number: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

             HEAD INDEX and HEAD SET for each PASS  
---------------------------------------------------------------  
 For 1 Pass Per Head Position:  
   Passes 1 - 14  
     Head Index    1  2  3  4  5  6  7  8  9 10 11 12 13 14  
     Head Set      1  1  1  1  1  1  1  1  1  1  1  1  1  1  
---------------------------------------------------------------  
 For 2 Passes Per Head Position:  
   Passes 1 - 14  
     Head Index    1  2  1  2  3  4  3  4  5  6  5  6  7  8  
     Head Set      1  1  2  2  1  1  2  2  1  1  2  2  1  1  
   Passes 15 - 28  
     Head Index    7  8  9 10  9 10 11 12 11 12 13 14 13 14  
     Head Set      2  2  1  1  2  2  1  1  2  2  1  1  2  2  
---------------------------------------------------------------  
 For 4 Passes Per Head Position  
   Passes 1 - 14  
     Head Index    1  2  1  2  1  2  1  2  3  4  3  4  3  4  
     Head Set      1  1  2  2  3  3  4  4  1  1  2  2  3  3  
   Passes 15 - 28  
     Head Index    3  4  5  6  5  6  5  6  5  6  7  8  7  8  
     Head Set      4  4  1  1  2  2  3  3  4  4  1  1  2  2  
   Passes 29 - 42  
     Head Index    7  8  7  8  9 10  9 10  9 10  9 10 11 12  
     Head Set      3  3  4  4  1  1  2  2  3  3  4  4  1  1  
   Passes 43 - 56  
     Head Index   11 12 11 12 11 12 13 14 13 14 13 14 13 14  
     Head Set      2  2  3  3  4  4  1  1  2  2  3  3  4  4  
 
---------------------------------------------------------------  
 For 8 Passes Per Head Position  
   Passes  1 - 14  
     Head Index    1  2  1  2  1  2  1  2  1  2  1  2  1  2  
     Head Set      1  1  2  2  3  3  4  4  5  5  6  6  7  7  
   Passes 15 - 28  
     Head Index    1  2  3  4  3  4  3  4  3  4  3  4  3  4  
     Head Set      8  8  1  1  2  2  3  3  4  4  5  5  6  6  
   Passes 29 - 42  
     Head Index    3  4  3  4  5  6  5  6  5  6  5  6  5  6  
     Head Set      7  7  8  8  1  1  2  2  3  3  4  4  5  5  
   Passes 43 - 56  
     Head Index    5  6  5  6  5  6  7  8  7  8  7  8  7  8  
     Head Set      6  6  7  7  8  8  1  1  2  2  3  3  4  4  
   Passes 57 - 70  
     Head Index    7  8  7  8  7  8  7  8  9 10  9 10  9 10  
     Head Set      5  5  6  6  7  7  8  8  1  1  2  2  3  3  
   Passes 71 - 84  
     Head Index    9 10  9 10  9 10  9 10  9 10 11 12 11 12  
     Head Set      4  4  5  5  6  6  7  7  8  8  1  1  2  2  
   Passes 85 - 98  
     Head Index   11 12 11 12 11 12 11 12 11 12 11 12 13 14  
     Head Set      3  3  4  4  5  5  6  6  7  7  8  8  1  1  
   Passes 99 - 112  
     Head Index   13 14 13 14 13 14 13 14 13 14 13 14 13 14  
     Head Set      2  2  3  3  4  4  5  5  6  6  7  7  8  8  
---------------------------------------------------------------

The following give the lists of the first track (head) for each channel for experiments using all heads in a pass. Channels using multiple tracks because of fan out and/or 2 bit mode use the listed track plus successive even or odd tracks. For the multiple pass per head position modes, the listed tracks are divided into groups and successive passes (at a head position) use the successive groups.

              FIRST HEAD per CHANNEL  
---------------------------------------------------------------  
    Tracks Per Channel:    8  
    Modes:                 (VLBA1:4, 2 bit)  
    First Heads:           2 18 3  19  
---------------------------------------------------------------  
    Tracks Per Channel:    4  
    Modes:                 (VLBA1:4, 1 bit), (VLBA1:2, 2 bit)  
    First Heads:           2 10 18 26 3 11 19 27  
---------------------------------------------------------------  
    Tracks Per Channel:    2  
    Modes:                 (VLBA1:2, 1 bit), (VLBA1:1, 2 bit)  
    First Heads:           2 6 10 14 18 22 26 30  
                           3 7 11 15 19 23 27 31  
---------------------------------------------------------------  
    Tracks Per Channel:    1  
    Modes:                 (VLBA1:1, 1 bit)  
    First Heads:           2  4  6  8 10 12 14 16  
                          18 20 22 24 26 28 30 32  
                           3  5  7  9 11 13 15 17  
                          19 21 23 25 27 29 31 33  
---------------------------------------------------------------  
    Mark~III Mode B with channels in ascending frequency order.  
    Sidebands should alternate.  
    First Heads:  18  4 20  6 22  8 24 10 26 12 28 14 30 16 32 2  
                  19  5 21  7 23  9 25 11 27 13 29 15 31 17 33 3  
---------------------------------------------------------------  
    Mark~III mode E with channels in ascending frequency order.  
    First Heads:  4   6   8  10  12  14  16   2  
                 18  20  22  24  26  28  30  32  
                  5   7   9  11  13  15  17   3  
                 19  21  23  25  27  29  31  33  
---------------------------------------------------------------

Mark III mode A is not normally used with VLBA systems because the gain of only 2 tracks over mode A is not worth the extra tape usage. When it is used, the assignments are special because a decision has to be made about what subset of tracks to use.

Perhaps an example will help clarify all of this. Consider an experiment that uses 2 passes per head position and 4 tracks per channel. There will be 4 channels and the following pattern is used for the first few passes.

Pass Head  Dir             Heads.  
      pos        Chan 1       Chan 2        Chan 3       Chan 4  
 1   -319  For | 2 4 6 8 | 10 12 14 16 | 18 20 22 24 | 26 28 30 32 |  
 2     31  Rev | 2 4 6 8 | 10 12 14 16 | 18 20 22 24 | 26 28 30 32 |  
 3   -319  For | 3 5 7 9 | 11 13 15 17 | 19 21 23 25 | 27 29 31 33 |  
 4     31  Rev | 3 5 7 9 | 11 13 15 17 | 19 21 23 25 | 27 29 31 33 |  
 5   -271  For | 2 4 6 8 | 10 12 14 16 | 18 20 22 24 | 26 28 30 32 |  
 6     79  Rev | 2 4 6 8 | 10 12 14 16 | 18 20 22 24 | 26 28 30 32 |  
 7   -271  For | 3 5 7 9 | 11 13 15 17 | 19 21 23 25 | 27 29 31 33 |  
 8     79  Rev | 3 5 7 9 | 11 13 15 17 | 19 21 23 25 | 27 29 31 33 |  
 etc.

Note that when there is both fan out and 2 bits per sample, the “sign” bits are fanned out over the first n tracks (eg 4 for VLBA1:4), and then the “magnitude” bits are fanned out over the next n tracks.

B.6 S2

The S2 system is no longer in use. This subsection of the recording systems section has been moved here for historical reasons.

The S2 system has been developed in Canada to support the Orbiting VLBI missions VSOP and Radioastron, in addition to ground based astronomy. It is based on VCR technology and is relatively inexpensive. It is being used in Australia on the AT and at a number of other sites around the world.

SCHED supports observations on telescopes that have S2 recorders and are controlled through the Field System (FS9.3.7 or higher). This is also done by creating a *.vex file in the VEX format (see section on MkIV).

The telescopes are characterized by RECORDER = S2 and CONTROL = VEX. Currently DAR = VLBA is completely supported (it could be possible to also implement DAR = MKIV). For any other DAR SCHED will attempt to schedule the observation with a “standard” S2 mode, not using any knowledge on the content of the “user signal”.

The modes supported for DAR = VLBA can be derived from a document “Compatibility of S2 and VSOPT recordings at S2 and VSOPT Correlators” by R. Wietfeldt, available at ftp::s2.sgl.ists.ca:pub/s2/svlbi/s2vsop_compat_memo_v*.ps.Z.

Because the S2 recorders work in a way conceptually different from VLBA (or MkIV) recorders, the user should bear the following in mind when scheduling for S2 recorders.

Please note that no operational tests with SCHED and S2 recorders have been completed yet, except for VSOP recording. Recently (Dec 2000) it was discovered that observations that use more than 1 group of transports (thus not VSOP modes) would not switch groups. This should have been fixed.

The S2 recorder internally works with a number of recorders which each have one head and track. The S2 box uses 1, 2, 4 or 8 recorders depending of the mode. In SCHED this is characterized by setting TPMODE to the number of groups will be used by the S2 recorder.

The concept of fan–in or fan–out does not apply to S2 recorders in SCHED.

Tape lengths for S2 tapes are specified as the length for standard US VCR recording in seconds. Thus, when the VCR cassette has 120 (minutes) on the label the tape lengths is 7200 (ft) in SCHED. European buyers should be careful; a ST-120 tape presumably is labeled SE-180, but should still be scheduled with TPLENGTH = 7200. The S2 LP is obtained by using low density for which the TPSPEEDL = 6.3 (ips) and SLP by using TPSPEEDH = 4.2 (ips). These speeds are chosen in order to simulate that a 120 minute cassette will last for 7200*12/(6.3*60)=229 minutes, consistent with the S2 documentation. For high density the same tape lasts for 343 minutes per group (multiply by TPMODE to get the total time).

S2 tape motion is supposed to be “adaptive”. The S2 recorders should start 2.5 minutes before a scan, stop only 0.1 minutes after the scan and generally continue to spin if any gaps are shorter than 2.6 minutes. This is the default and only mode of control for S2 recorders through SCHED.

B.7 Green Bank 140’.

The NRAO 140 foot antenna is no longer in use. The GBT will be used for VLBI, but has not been tested as of January 2001. (But it has been in use by 2007 for a while and there is now a GBT section). This section will need a lot of work when it starts being used. It is expected that the Green Bank card type of output is now obsolete.

BELOW IS OLD INFORMATION ON USING THE 140’.

Frank Ghigo (email of 25 Mar 1997) asks VLBI and VSOP observers of the 140-foot at Green Bank to please allow enough time for pointing checks to be done during the schedule. For C-band (5 GHz) schedule 10 minutes of no observing about once every three hours. At K-band (22 Ghz) allow 10 minutes every two hours. At frequencies below 5 GHz no extra pointing checks are necessary.

Note that pointing can be specified through the use of the PEAK. However it is also possible for the local staff to insert the pointing observations if adequate gaps are left and the user’s intentions are made clear in the cover letter. Actually it is a good idea to make the user’s intentions clear in the cover information regardless.

Green Bank (140’) is the only station for which SCHED can still request automatic measurements of the antenna temperature of a source. The parameters TANT1 and TANTSTA1 are used to control this capability. Note that a Tant measurement takes about a minute and the antenna is off source part of the time so such measurements should be done before a recording scan starts.

Green Bank (140’) does not have computer control of the pcal injection. Therefore do not expect the pulse cal to be turned on and off on a per-scan basis. The support people will try to determine from your schedule or cover information if the pulse cal is desired and set it accordingly. It is wise to make your desires clear in the cover notes, especially if you want pcal off. Note that the pcal tones are injected in the IF, not at the receiver as at most sites.

B.8 Installation on Mac OSX 10.3 in 2003.

For those with older systems, here are a few details for Mac OS X users based on my experience installing SCHED on a Mac iBook G4 system in Dec 2003 with OS X version 10.3 (Panther). Note that, for OSX 10.5, the installation was somewhat smoother with the main issue being a need to switch from g77 to gfortran. PGPLOT could be downloaded from the Fink. For OSX 10.3, before installing SCHED, the code tools had to be installed (the installation package was already on disk, but not yet installed) and X windows had to be installed from the OS X installation CD 3 (not CD 2 as some documentation stated). The code tools include gcc, but not g77 (why?). A binary version of g77 compatible with Panther was obtained from hpc.sourceforge.net. It installed itself on download and simply worked. PGPLOT was installed. There was no PGPLOT configuration file (.conf file) provided for OS X (there probably is one now). I made a local.conf file starting with the one from ../src/sys_bsd/g77_gcc.conf. The following two lines were different:

 FFLAGD="-fno-backslash"  
 LIBS="-L/usr/lib -lgcc -L/usr/X11R6/lib -lX11"

The routine that makes the font file (pgpack) caused some trouble while I was messing with various variants on the above, but eventually worked. I suspect problems with big vs little endian byte orders, but I’m not sure. Note that pgplot version 5.3 has OS X as a standard OS type. This version was not released as of Aug 2008 (may never be), but might be available if you ask nicely.

Once the X windows environment, gcc/g77, and PGPLOT were ready, SCHED compiled and ran with the Makefile set up for Linux/g77 and the and the following two modified lines (one just depends on the location of PGPLOT and the other helps it find the gcc libraries): XLD = -L/usr/lib -lgcc -L/usr/X11R6/lib -lX11 # Mac OS X (ie DARWIN) LPGPLOT = /usr/local/pgplot The architecture still claimed to be LINUX and the g77 compiler flags were the same. That’s all it took! It compiled and passed the verification tests. If you are using FINK, some details may be different.

If you run into problems with some missing .h files, you might have a mismatched OS version and XCODE version, as I did.

I now have SCHED on a Powerbook G4 (OSX 10.3 still) and that is now one of the SCHED development platforms.