This release, 11.8 (April 2023), is an update to the earlier 11.7 (June 2022) release, containing mostly minor updates including a bugfix for autopeak and new source catalogues.
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 is intended for use with 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 here for sched_11.8 or 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 Jay Blanchard. 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 Jay Blanchard 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.
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 MARK6. 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 in HTML. 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.
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:
Different types of VLBI observations:
VLBA observing: Most of this manual.
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.
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.
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.
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:
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,
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.
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:
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.
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:
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.
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.
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.
If the above file were named uvcov.key, it could be run with the commands:
When the plot section is reached, a graphical interface will appear that is reasonably obvious how to use.
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):
(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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 MHz | DBBC2 with upgraded firmware and DBBC3 |
| 6 | 10-1024 MHz | DBBC3 |
| 3 | 1536-2048 MHz | DBBC3 |
| 5 | 1150-1750 MHz | DBBC3 |
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 1024∕231 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).
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.
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:
Argument: Name of up to 8 characters.
Options: Any name.
Default: None
Usage: Defaults to previous value - don't do it!
Example: LINESET='H2O'
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
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).
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).
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.
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.
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.
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.
.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
CORNOTE1: Notes for correlator operations.
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.
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, 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 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 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 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 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
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 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 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 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(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
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 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 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 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 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 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 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 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 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 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 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 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 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'
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 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
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 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
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 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 is a switch that turns on some debug printouts. It is unlikely to be useful to users, only to programmers.
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 (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 is an obsolete form of the parameter DOPPLER. It is no longer recommended because of possible confusion with DO PCAL.
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 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
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 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 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 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
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
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 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 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 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 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 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 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: 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 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 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 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 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 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 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
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 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
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
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
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
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
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
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 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:
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
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
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
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'
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
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 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 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 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 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 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
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
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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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:
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.
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 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 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 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:
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 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 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 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 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 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:
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 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 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 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 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 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 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 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
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 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:
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 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 sets the optimization mode. The valid modes are:
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.
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.
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.
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.
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 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 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 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.
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 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'
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, 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 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 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 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 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 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 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 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 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
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 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'
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.
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 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 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 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 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 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 = 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 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 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 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 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 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 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 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
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
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 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 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 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 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 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 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'
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 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
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 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:
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 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 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 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 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.