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

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

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

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

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

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

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

Contents

0.1 Important Notes - Please check these

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

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

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

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

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

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

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

0.2 Links to Manual Sections and to External Information.

New users — please read:

Introduction: General information about SCHED.

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

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

Running SCHED: How to get it to execute.

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

Observing strategy: Some tips.

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

The SCHED input files and their input parameters:

The main input schedule.

The Station Catalog.

The Source Catalog.

The Setup Files.

The Frequency Catalog.

The Tape Initialization File.

Spectral Line Frequencies.

Different types of VLBI observations:

VLBA observing: Most of this manual.

VLA observing for VLBI.

General information on non-VLBA systems.

Mark IV (and VLBA4) VLBI observing.

Non-VLBA telescopes with VLBA recorders.

S2 VLBI observing. Obsolete.

VLBA Single-Dish observing (mostly test observations).

Detailed advice and information:

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

Making plots: UV coverage, elevation vs time etc.

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

Tape management: Obsolete since the advent of disk recordings.

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

Special concerns for specific observartories.

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

Related programs: Where does SCHED fit in.

Station codes: A list, a bit dated.

Changes to SCHED: A list of recent SCHED changes.

A history of SCHED: A brief history.

Some links to other sources of information:

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

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

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

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

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

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

Chapter 1
INTRODUCTION

1.1 Overview

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

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

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

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

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

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

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

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

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

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

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

1.2 Keyin Free-format Input

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

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

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

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

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

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

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

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

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

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

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

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.

1.3 SCHED Input and Output Files

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

Main Schedule Input File:

This is the file that contains the details of the particular project. It can have the most of the other files imbedded in it. This file must be created by the user. This file should be given a name like bv016.key for project BV016. See the /schedb examples for numerous samples.

Source Catalog:

These files contain the information about the sources, especially names, positions, and, for line sources, velocities. There are standard source catalogs, although the user may need to add non-standard sources. Source catalog entries can be included in the Main Schedule Input File. There are two standard source catalogs which are $SCHED/catalogs/sources.gsfc, and $SCHED/catalogs/sources.petrov, which contains sources respectively from from the Goddard geodesy group and from Leonid Petrov. The links above are actually to symbolic links to the latest catalog from each source as of the time of the SCHED release. These catalogs contain thousands of sources (near 10,000 in Petrov’s case), so the old catalog that contained a few sources from elsewhere has been abandoned. Two external catalogs can be specified if one wishes, for example, to use the standard one for calibrators and another for multiple phase centers.

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

Station Catalog:

This file contains information about the antennas including names, positions, slew limits, horizons etc. There is a standard station catalog that should suffice for nearly all users. If not, entries can be included in the Main Schedule Input File. Station positions may stored separately in the Location Catalog. The standard station catalog is $SCHED/catalogs/stations_RDBE.dat. The old version for use with the legacy VLBA systems is still $SCHED/catalogs/stations.dat. By the next SCHED release, it is likely that stations.dat will be the RDBE version and the legacy version will be renamed or removed.

Location Catalog:

This file contains station locations. The standard version reflects the locations and velocities used on the VLBA correlator. It is documented along with the Station Catalog because they are tightly coupled. The Locations Catalog is optional since it is not needed if the station locations are specified in the Station Catalog. It exists separately for ease of maintenance. The standard location catalog is $SCHED/catalogs/locations.dat.

Setup Files:

These files contain the details required to configure the hardware at the stations. Different projects using the same hardware configuration can use the same setup files. There are many standard setup files are located in $SCHED/setups.

Frequency Catalog:

This file contains information about valid frequency setups at the stations. The RF ranges that can be covered and the local oscillator and polarization of each IF are given. SCHED can use this information to provide good defaults for many parameters in the setup files. The standard file should be used. Any non-standard information can be in the setup files. This file cannot be imbedded in the main input file. The standard frequency catalog, for use with the RDBE systems, is $SCHED/catalogs/freq_RDBE.dat. The legacy version is still available. It is $SCHED/catalogs/freq.dat The main difference is that the VLBA IFs are assumed to be between 512 and 1024 MHz in the RDBE version, not 500 and 1000 MHz as in the legacy version. By the next SCHED release, the RDBE version will likely become $SCHED/catalogs/freq.dat and the legacy version will be renamed or removed.

Tape Initialization File:

This file tells SCHED the properties of the tape systems at the stations and where to start on each tape. Since tapes are no longer in use, this file is mostly obsolete. However it can be used to specify use of a recording system at a station that is different from what is given as the default in the station catalog. This is generally only useful during periods when stations are transitioning between different recording systems. Note that many old files, often used as templates, contain tape initialization sections. These should be removed.

Reference Pointing Control File:

SCHED can insert scans for reference pointing at high frequencies on the VLBA and VLA. This file contains information needed to control that function. It will only be of interest for observations above 15 GHz on the VLA and at 86 GHz on the VLBA. The standard reference pointing control file is at $SCHED/catalogs/peak.cmd There is a special version related to reference pointing when using the new wideband (RDBE/MARK5C) system on the VLBA. It is $SCHED/catalogs/peak_RDBE.cmd.

Spectral Line Rest Frequencies:

SCHED can adjust the observing frequency to remove the Doppler shifts due to the motions of the Earth around the Sun and to the Sun with respect to a desired reference frame. To do this, SCHED needs to know the rest frequency of the line being observed. This is given in a lineinit section imbedded either in the main file or in the reference pointing control file. There is a file, $SCHED/catalogs/linefreqs.dat, distributed with SCHED, that gives the rest frequencies for many of the maser lines commonly observed with VLBI.

Ephemeris file:

SCHED can be used to schedule observations of planets. To do so, it obtains positions from a JPL ephemeris file. Mostly this is used for single-dish calibration observations.

Satellite file:

SCHED can also be used to schedule observations of satellites. To do so, it obtains orbital elements from the SATFILE or TLEFILE which are specified in the SATINIT section. This is used for holography and for spacecraft navigation projects. Satellite tracking is discussed in the Satellite tracking section

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

Summary File:

This file gives a rather extensive summary of the setups and observations. This is the most useful output file for the user as it shows how SCHED has interpreted the input commands. The file will be called, for example, bv016.sum. The items displayed for each scan can be controlled with the parameter SUMITEM.

sched.runlog:

This file reflects most of what you see on the screen when SCHED is running, plus may contain additional messages that help debug problems should they occur.

Operator Schedule Files:

These files, of which there is one per antenna, give much more information about the schedule than can be included in the summary file and are useful when that level of detail is needed. They were originally meant for the use of operators of manually controlled antennas, but now most antennas are computer controlled and these files are more useful for the scheduler. The files are named, for example, bv016sch.pt.

VLBA type Antenna Control Files (crd files):

These files provide the legacy on-line control systems of the type found at VLBA antennas with the information they need to control the observations. There is one file per antenna that uses a VLBA control computer for either full control of the station or for control of just the data acquisition system (data recorders, baseband converters etc.). The files are named, for example, bv016crd.pt. Note that the VLBA antennas currently are in transition with some items controlled by the legacy system and some by the new control system which is commanded using the VEX file.

VEX file:

This is the main output file needed by the stations for antenna and recording system control and by the correlators to process observations. It is now used by most VLBI systems around the world, not just the Goddard “Field System”. For the VLBA, it is used to control the RDBE, MARK5C, and some antenna data path switches. The legacy system, commanded by the crd files described above, still controls the antenna pointing among various functions. Both are needed. A single VEX file describes the observations for all antennas.

V2D file:

This is a template correlator setup file for the (VLBA) DiFX correlator. Information that needs to be modified from what is in the VEX file can be specified by the analysts in this file. It is also the path to transmit information about multiple phase centers per pointing to the correlator.

Flag file:

SCHED writes a file with the .flag extension that can be helpful in data processing. It contains flag entries, in the format appropriate for the AIPS task UVFLG, that cover the times when data are being recorded, but the antenna is expected to be slewing. For the VLBA, the monitor flags would usually take care of such times, but for other types of stations, such information is not always available from the logs.

Preempt file:

Starting in Oct. 2011, the VLBA will be providing observations of up to 1.5 hours on the Pie Town to Mauna Kea baseline to the USNO for EOP determination. This is in return for financial support for operations. These observations will preempt the scheduled project on the two stations. There is some flexibility to choose the exact time of the preemption so the user has been given some ability to guide the choice. Important scans can be protected using the PREEMPT parameter. Information in the preempt file, which is also in the summary file, is used by operations when picking the time for the EOP observations.

Plots:

Sched can make plots of u-v coverage and of various combinations of azimuth, elevation, paralactic angle, hour angle, UT, and GST against each other. Plots can be made of the time antennas are up. Plots can be made of beams. The plot capability can be used to plot the distribution of your sources, and of the all sources in the catalog, on the sky. This is useful for looking for calibrators. In advanced modes, stations can be moved around to explore UV coverages in array configuration design projects. Also quality factors can be calculated and plotted with contours over a map of the stations. There is interactive control over the plotting, the only interactive part of SCHED. Much of this capability is mainly useful in experiment planning.

DiFX configuration file:

When making jobs for the DiFX correlator, especially as used for the VLBA, a .v2d file is used to give information not readily deduced from the .vex file. SCHED now writes a template for that file. That file is also be used to pass lists of phase centers when utilizing the DiFX multiple phase center capability.

Optimized Schedule:

When one of SCHED’s optimization modes is turned on, or geodetic segments are requested, the program writes out a file, such as bv016.sch containing the basic scan inputs for a new main schedule file. If desired, the user can use this to construct, and perhaps modify, a new optimized main schedule input. This used to be the way all optimized schedules were constructed, but now that SCHED fully processes an optimized schedule, it is rarely used or needed. The newer use is to make it easy to reproduce geodetic segments when something else is changed that would otherwise change the results of the optimization.

frequencies.list:

If the user specifies the parameter FREQLIST, SCHED will read the frequency catalog and make a table of all known setups which can be used to make observations in the specified frequency range. Then SCHED will quit without doing further processing. This is useful for planning and for information while making setup files.

1.4 Examples

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

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

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

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

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

manual_2.key

This file is shown below as the first example. It is a fairly typical SCHED input file for a VLBA plus the GBT observation. It uses defaults where it can and is relatively simple. This example is a good file to use as a template for making new schedules. This file has not been updated from MARK5A to MARK5C.

manual_1.key

This file will produce the same schedule as the first example. However, for demonstration purposes, far more parameters are actually specified in the input file. This includes having at least parts of all auxiliary input files (catalogs etc) imbedded. It is fairly complicated and contains a lot of comments in an attempt to show many SCHED features and give some advice on scheduling strategy. It has been updated to use the RDBE/DDC system on the VLBA and the WIDAR on the VLA.

manual_simp.key

is the second example below. It is a very simple file that can be used to make plots for experiment planning purposes. Because of the lack of cover information and because of the special optimization mode used, it cannot be used to produce telescope control files.

egplan.key

is much like [manual_simp.key]. It is a simple schedule to assist in experiment planning. It is a bit more complete than manual_simp.key.

eglst.key

is a sample schedule using LST in the way requested for dynamic scheduling projects on the VLBA.

egvlba.key

is a sample schedule for VLBA observations. It demonstrates band switching and some recording control procedures not in manual_2.key. It also demonstrates providing PREEMPT=EXTRA scans on the ends of the project so that operations might be able to provide extra data if there is a gap that cannot otherwise be filled between projects.

eg24.key

is a sample schedule of a simple project on the VLBA, but one that goes for 24 hours. For dynamic scheduling, it is useful to be able to wrap such schedules to use a different start time. This shows how to put in comments for the schedulers to aid that process and shows how the schedulers can use parameters WRAP24 and DOSCANS to simplify the wrapping process. Note, this has not yet been updated from MARK5A to MARK5C.

egOH.key

is a sample spectral line file for VLBA observations of several OH masers transitions.

egcent.key

is a sample showing how to specify multiple phase centers for a pointing center for the DiFX correlator.

egdelzn.key

demonstrates how to use the capability in SCHED to add automatically short geodetic segments for the purpose of atmospheric calibration delay. Note that similar segments, with very short scans, can be added for tropospheric opacity calibration. This example also shows the use of the PREEMPT parameter to protect specific scans from preemption at Pie Town and Mauna Kea for daily EOP observations of up to 1.5 hr.

dqhiel.key

demonstrates how to use the HIGHEL optimization mode which can pick the scan with the highest elevations across the array from among a group of suggested scans. It is useful for testing but also can be useful for picking fringe finders etc. This schedule is based on the regular data quality tests.

egrdbe2.key

demonstrates a SCHED file for use with the new digital backend and Mark5C recorders being deployed on the VLBA and elsewhere. This one is relatively simple and uses the PFB personality which gives many channels of fixed frequency and bandwidth. It does exercise the mode where one station (GBT) has to observe in the opposite sideband from others.

rdbepfb.key

is a stripped down version of egrdbe2.key that shows a rather basic schedule for the VLBA only using the RDBE with the PFB personality. It uses a SCHED standard setup so the user doesn’t need to set the configuration information.

egcwide.key

Example sched input for a VLBA using the RDBE with the PFB personality and the wideband 6 cm receiver. Setups are given that use dual polarization in one pair of IFs and that use single polarization in two IFs at very different frequencies.

egddc.key

demonstrates a SCHED file for use with the new digital backend and Mark5C recorders being deployed on the VLBA and elsewhere. This one allows flexible baseband frequencies and bandwidths, but provides fewer channels than the PFB personality.

egddc2.key

demonstrates a SCHED file for use with 2 RDBE’s and 8 channels from the DDC personality. Otherwise it is a fairly simple VLBA schedule. The deployment of 2 RDBE’s is expected in early 2013.

manual_line.key

is the example that is included in the spectral line section of this manual. It is for VLBA and GBT observations of 7mm SiO lines. It is more complicated than egOH.key and also demonstrates setting GBT frequencies and many other setup parameters that were defaulted in egOH.key. This file has not been updated from MARK5A to MARK5C.

eg512.key

is a sample schedule for the VLBA that uses the 512 Mbps mode.

eg512g.key

is a sample schedule for the a global observation that uses 512 Mbps with the RDBE.

eg1024.key

is a sample schedule for the EVN that uses the 1024 Mbps mode with DBBC, VLBA4, and MKIV systems.

eg2head.key

is a sample schedule for an EVN observation that uses the 512 Mbps mode. This uses 2 heads on one tape drive on Mark IV stations. VLBA4 and DBBC stations are included. Note that it is possible to do 512 Mbps on the VLBA and Mark IV stations simultaneously. The VLBA uses 2 drives while the Mark IV systems use 2 heads. This is actually based on a network monitoring observation.

egglobal.key

is a sample file for simple continuum observations involving the VLBA, the EVN,and the GBT. The VLA has been removed because this example uses the legacy recording system which is no longer supported at the VLA. This file has not been updated from MARK5A to MARK5C.

egglobalOH.key

is a sample file for line observations involving the VLBA, the EVN,and the GBT.

egvsop.key

is a sample schedule for Mark IV / VLBA observations specifically using modes appropriate for observations with the Japanese VLBI satellite, VSOP. It will produce VEX format schedules for stations that use the field system and VLBA format files for those stations that need them. VSOP (HALCA) is no longer operational, but the VSOP-2 project has started so this example has been retained. It will be modified for VSOP-2 when that project is far enough along to make it clear what is needed. This file has not been updated from MARK5A to MARK5C.

eg3mma.key

is a VLBA schedule for observations at 86 GHz. There is special emphasis on reference pointing, which is done explicitly in this file. This file uses the RDBE_DDC at 2 Gbps using 8 channels of 64 MHz each.

eg3mmb.key

is another 2Gbps VLBA schedule for observations at 86 GHz. There is special emphasis on reference pointing, which is done automatically in this file based on information in the peak.cmd file.

eg3mmc.key

is yet a third VLBA 3mm schedule, again using automatic insertion of pointing scans. But this time, the file with the commands controlling that insertion is inserted in the main schedule file and is somewhat simplified from that in eg3mmb.key This file does not create the separate new and old system files needed for reference pointing on masers while observing with the new RDBE wide band system with the PFB personality. For instructions on how to do that, please see eg3mm_rd2.key. This file has not been updated from MARK5A to MARK5C.

eg3mm_rd2.key

is similar to eg3mmb.key, but shows how to make reference pointing observations, when using the RDBE wide band system with the PFB personality which uses fixed 32 MHz channels and cannot be fine tuned. It uses the crd parameters to specify the allowed bandwidth and frequency, including using Doppler calculations, to set the legacy system as desired.

vips11.key

shows use of OPTMODE=HAS for automatic scheduling. This mode tries to obtain a requested number of scans on each source and spread them reasonably evenly over the time available. It pays some attention to minimizing slew times. It is meant to simplify scheduling of projects that try to image a number, perhaps large, of sources using multiple snap-shots on each. It was originally provided for the VIPS project but should be useful for many other programs.

evn_cont_strong.key

is an example of EVN observations at 18cm. The observing pattern is an 11 minute cycle with 2 minutes on a calibrator and 9 minutes on a target source. This observation is at 128 Mbps.

evn_cont_strong_pol.key

is essentially the same schedule as evn_cont_strong.key, but with a D term calibrator and a polarization position angle calibrator added.

evn_cont_weak_256.key

is phase referencing schedule for the EVN with a 5 minute cycle time using 256 Mbps.

evn_cont_weak_512.key

is a similar phase referencing schedule for the EVN, but uses 512 Mbps which requires 2 headstacks.

evn_cont_weak_snap.key

is an EVN schedule for 256 Mbps observations of multiple snapshots using phase referencing.

evn_line_hi.key

is for EVN observations of an extragalactic 21-cm HI source.

evn_line_meth.key

is for EVN only observations of the 6.7 GHz line of methanol in a galactic source.

eg5cm.key

is a sample schedule for the EVN and EVLA that observes near 6.7 GHz. It is the same as evn_line_meth.key, but with the EVLA added.

egmk5vex.key

is for EVN only observations using the Mark5 system. It is based on a Network Monitoring schedule. Note that it is a bit dated in that it uses the Mark5A system for a VLBA station which no longer has that option.

hsa1cm.key

is a sample schedule for the High Sensitivity Array (HSA - VLBA + GBT + Effelsberg) at 1cm. This file does not include the VLA and Arecibo.

hsa21cm.key

is a sample schedule for the High Sensitivity Array (HSA = VLBA + GBT + Effelsberg + Arecibo (VLA removed)) at 21cm. The schedule uses the legacy system which is not available at the VLA so the VLA has been taken out for now.

hsaddc.key

is a rather complex example that uses the RDBE with the DDC personality on the VLBA, VLA, GBT, and Effelsberg. There are segments at 6cm, 1cm, and 3mm. It exercises array phasing at the VLA, reference pointing at all of the telescopes, and Doppler tracking.

lba.key

is a sample schedule for the Long Baseline Array in Australia.

lba_h20.key

is a sample schedule for the Long Baseline Array in Australia using LBA DAS/Recorder only. Observations are at the 22 GHz water line.

lba_oh.key

is a sample schedule for the Long Baseline Array in Australia using LBA DAS/Recorder only. Observations are at the 1.8 GHz OH line.

lba_mk5.key

is a sample schedule for the Long Baseline Array in Australia when some MARK5 stations are included.

planvla.key

is a planning file similar to the other VLBA planning files, but has all 27 stations of the VLA A configuration. You can use this to explore VLA uv coverage etc. It should still work despite the current (2014) inability to schedule the VLA for other than VLBI. It doesn’t actually create observing files.

doptg.com

is a script that creates and runs VLBA pointing observations. It exercises one of the optimization modes to allow the same script to be used for any time slot for any time of year. This example will not be run by the Verify script if the site is not at NRAO because the ephemeris routines used for pointing at planets will not generally be available. It is also not of much interest beyond the staff responsible for maintaining the VLBA.

doptg2.com

is a script that creates and runs VLBA pointing observations. It is very much like doptg.com except that it uses the DOSTA parameter to allow the same script to be used for stations with 3mm and stations without 3mm.

egsat.key

demonstrates scheduling a satellite observation using both MER-B and Stardust. It also includes Mars to exercise the planet option. These capabilities are unlikely to be of interest outside of the AOC. In fact, the required NAIF software libraries would hugely increase the size of the SCHED distribution and are not normally included. This file has not been updated from MARK5A to MARK5C.

dq415.key

is a data quality test file from early 2014 that uses the RDBE and MARK5C. It samples most of the RF bands available on the VLBA.

mt506.key

is one of the weekly VLBA integrity check observations from the MARK5A era. It is here mainly to exercise SCHED in a mode that uses lots of setup files. It is similar to the more modern dq415.key but uses the outdated recording system. It should probably be removed soon.

jvla.key

is an example covering use of the VLA as a phased array for VLBI. This version uses the 32 MHz output baseband bandwidths of the WIDAR to create recordings that can be played against 4 of the 16 channels created by the PFB personality of the RDBE on the VLBA.

n2227.key

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

pfbsettst.key

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

egsat.key

is a sample VLBA observation of spacecraft with bsp ephemeris files. Note that the satellite tracking in SCHED uses the NAIF software from JPL. The object libraries for linux g77 and gfortran are included with SCHED, but may not be usable on all machines. The code is not exported. Normally, other than in the AOC, the stub routines are used and SCHED cannot deal with satellites. Also, SCHED does not have a way to pass the necessary site dependent, moving source positions to non-VLBA stations.

tlesat.key

is a sample VLBA observation of spacecraft using TLE ephemeris files. See the note above (egsat.key) about the satellite tracking software. It applies here too.

newsyn.key

is a VLBA test observation to check the performance of the new front end synthesizers being designed in 2013-2015. Those synthesizers have finer tuning steps than the current ones (10kHz vs 200 or 300 MHz). They are not yet deployed except at a couple of sites so this example is not yet of interest to users.

tstsets.key

is a VLBA test observation that tests the standard setups used with the RDBE/DDC. Only bit rates under 512 Mbps are tested. This is not a maintenance schedule, not one users would likely want to emulate.

piggyback.key

is a VLBA test observation that observes with both the Mark5A and Mark5C systems. As of early 2015, only two VLBA stations even have Mark5A so this is only of interest to VLBA testers.

1.4.1 A Basic VLBA Schedule.

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

1.4.2 A Minimal Schedule for Planning.

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

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.

1.5 Plotting

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

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

(substituting your file for the bv016d.key.

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

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

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

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

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

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

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

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

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

1.5.1 Keyin Input for Plotting (obsolete)

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

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

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

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

Plotting Input Parameters (Terminal):

The KEYIN inputs to the plotting section of SCHED are:

PLotfile

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

SEtnum

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

TYpe

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

XAxis

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

YAxis

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

XLeft and XRight

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

YBottom and YTop

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

SOurce

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

STation

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

REstart

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

FInish

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

EXit

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

Chapter 2
INFORMATION AND ADVICE ON SPECIFIC TOPICS

2.1 Using SCHED for Project Planning

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

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

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

2.2 Scheduling Tips

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

2.2.1 Observing Strategy

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

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

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

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

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

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

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

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

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

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

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

“VLBA Information for Astronomers”

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

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

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

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

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

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

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

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

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

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

2.2.2 Scan Times

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dealing with Formatter Reconfigurations

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

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

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

Adjusting the Scan or Recording Start Time

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

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

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

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

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

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

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

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

2.2.3 Dynamic Scheduling

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

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

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

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

2.2.4 Management of Data Recordings

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

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

2.3 Recording Systems.

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

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

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

2.3.1 Recording Systems History and Background

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

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

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

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

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

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

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

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

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

Meanwhile, other potential future recording systems are being investigated.

2.3.2 Recording Systems Control

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

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

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

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

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

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

2.3.3 MARK5 and EVLBI

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

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

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

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

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

2.3.4 VLBA

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

2.3.5 MARK IV (PCFS)

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

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

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

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

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

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

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

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

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

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

2.3.6 NON–VLBA Telescopes with VLBA Recorders

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

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

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

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

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

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

OLD SYSTEMS:

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

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

NEW SYSTEMS:

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

2.4.1 The RDBE system

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

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

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

TERMINOLOGY:

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

RDBE PFB PERSONALITY:

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

RDBE DDC PERSONALITY:

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

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

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

VLBA TUNING RESTRICTIONS:

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

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

EXAMPLES:

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

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

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

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

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

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

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

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

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

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

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

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

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

REFERENCE POINTING WITH THE RDBE:

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

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

PARALLEL MARK5A and MARK5C RECORDINGS:

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

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

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

2.4.2 DBBC:

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

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

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

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∕2³¹ MHz = 0.476Hz, but its use is not advised and it is not currently supported by SCHED.)

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

2.4.3 OTHER DIGITAL BACKENDS:

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

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

2.5 Spectral Line Observations

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

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

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

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

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

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

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

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

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

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

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

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

DOPPLER and NODOP turn the Doppler calculations on and off.

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

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

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

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

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

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

LINESET:

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

Argument: Name of up to 8 characters.

Options: Any name.

Default: None

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

Example: LINESET=’H2O’

RESTFREQ:

Rest frequencies.

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

Options: Any value.

Default: 0

Usage: Defaults to previous value.

Example: RESTFREQ=22235.08

ENDLINES:

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

Argument: None.

Options: None.

Default: Not specified.

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

Example: ENDLINES /

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

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).

2.6 Reference Pointing

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

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

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

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

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

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

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

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

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

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

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

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

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

The input parameters for the PEAKFILE are:

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

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

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

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

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

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

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

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

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

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

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

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

2.7 Multiple Phase Centers

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

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

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

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

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

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

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

2.8 Automatic Insertion of Geodetic Segments

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

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

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

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

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

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

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

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

The algorithm:

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

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

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

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

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

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

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

2.9 Scheduling the VLA

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

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

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

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

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

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

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

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

ARRAY PHASING:

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

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

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

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

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

REFERENCE POINTING

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

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

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

OTHER CONSIDERATIONS

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

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

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

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

2.10 Special Concerns for Specific Observatories

.

WARNING: UNDER CONSTRUCTION!!!

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

This section is still woefully incomplete.

2.10.1 Green Bank Telescope.

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

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

2.11 Single Dish VLBA Observing

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

Some items of special interest for VLBA scheduling are:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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