This section is only needed if you do not have access to an installed copy of SCHED.
It is important that users obtain and use the latest version of SCHED when scheduling observations. SCHED is evolving with time to add new features, to correct bugs, to keep up with hardware changes, and to enhance its ability to prevent errors from being made in schedules, based on experience. There are typically one or two releases each year and they are announced on the VLBI email exploder. At institutions where there are several VLBI users, someone should be in charge of making sure that the latest version is available. When that option is not available, the user should check that he/she has the latest version before attempting to schedule a project.
The SCHED software, catalogs, auxiliary files, and documentation all reside in subdirectories under a parent directory. Installing SCHED involves unpacking the tar file of the distribution into such a directory. If a canned executable is available for your type of computer, it can hopefully, used as is. Otherwise it will be necessary to compile the program. The SCHED environment variable should be set to the root directory where SCHED is installed. The PGPLOT subroutine library is required. See below if you need to install it.
The installation can be tested using the Verify script in the examples subdirectory. That script runs all the examples and compares the results with results obtained at the time the release was created.
SCHED is written in FORTRAN 77 using only a few common extensions from the standard. Development has occurred on a variety of machines including VAXes, PCs, SUNs and Macs. Current development is done under Linux and Mac OSX, with pre-release testing on a Sun. Old versions were tested on Hp, SGI, IBM (AIX), and DEC Alpha, but such machines are no longer being used for SCHED as far as I know. A big “thank you” to Franco Tinarelli at Bologna for performing many of these tests. Machine dependent code has been isolated in special subdirectories under the src/Cit code directory. There are very few. All other FORTRAN files should compile without changes on a wide variety of machines. Note, however, that all current testing is under one or another flavor of unix. There has been no recent testing under other operating systems. This will only change if there is pressure to do so. Please inform the developers if you install it on something else.
Note that the usual fortran compiler on unix machines (including Macs) these days are those from the GNU Project. In the past, the compiler was g77. That works with gcc versions 3 and lower. But development of g77 is long finished. For gcc 4 and higher, you must use gfortran which was written from scratch. We are in the process of switching the support of SCHED to gfortran and have done so for various architectures as can be seen in the configure scripts. For some older versions, we may not bother switching, but simply stop supporting, for example, 32 bit machines. By stop supporting, we mean not provide configure scripts or test before releases. It is likely you could still use such machines. We will also need to migrate the spice code for spacecraft tracking before we can abandon g77 completely.
If you plan to support SCHED under more than one computer architecture, you may wish to have subdirectories under bin and point to the appropriate one in the PATH environment variable. Or you may wish to have entirely separate installations.
To install SCHED, the following steps can be followed. Users of anything but unix or linux (who don’t exist as far as we know) will have to make some modifications.
Users of Mac OSX will need to have X windows and the compiler installed. Also for full functionallity, pgplot should be installed. There are some more details at the end of this section.
Note that, after this step, a local html version of this manual will be available in the doc/sched/sched.html under the parent SCHED directory ($SCHED). Your browser will probably run much faster pointing at that version than at the version at NRAO.
Robert Mutel provided the following suggestion if you are running into problems on a MAC with the use of the pgplot libraries (complaints about being a FAT file): Edit the PGPLOT makefile to eliminate the ranlib indexing steps, and add a ’s’ option to the ar steps (this is equivalent to indexing with ranlib, but ranlib chokes because it cannot read ’fat’ libraries, which contain both 32bit and 64 bit versions of the routines. ’Fat’ libraries seem to be created by default by ar, at least in the recent Mac OSX release.
There is some oddity that has been seen on Mac OSX (May 2008) where it is not equivalent to just type make when the Makefile is what you want and typing, for example, make -f Makefile.MacOSX. The latter doesn’t seem to work with what look to be problems finding libraries. We don’t understand it.
Note that the Makefile requires the use of GNU make. Check for GNU make on your system. It is installed on many if not most and is the standard make under Linux and OSX. If you don’t have it, it can be obtained from prep.ai.mit.edu. Also a version (probably not current) is available in the same ftp area as SCHED.
SCHED can be compiled with or without the plotting capabilities. It is highly recommended that you compile with those capabilites. To do so, you will need PGPLOT (version 5.2 or later) installed on your system. See above for more information on getting PGPLOT if you don’t already have it.
There is also a stub for the routines related to use of the JPL ephemeris, in case that code causes problems. The JPL routines are used for observations of planets, which are probably only of interest for single-dish testing of the VLBA by staff. Using the stub requires changing some comments in the Makefile. Similarly, there is a stub to avoid using the NAIF software related to satellite tracking. The normal user will use that stub because the NAIF libraries are not normally distributed with SCHED.
Some VAX FORTRAN features that are commonly supported by other FORTRAN compilers remain in the code. These features are supported by all of the compilers that we are aware of that are being used for SCHED currently. They include long variable names, in-line comments, and END DO. If you have problems with these features, please email firstname.lastname@example.org. Considerable use was made of the SLALIB (STARLINK) routines for precession, etc. These routines use long variable names so removing this non-standard feature would not be easy. (email permission to use the FORTRAN SLALIB routines has been obtained from P. Wallace, although the version under the GNU license was installed in March 2013).
If the code or any other files are moved from a unix or VMS machine to a machine using DOS or Windows, beware that the end-of-line characters are different. At least on SUN and Linux, a pair of utilities unix2dos and dos2unix can be used to fix the files. As of Dec. 2009, SCHED under Unix and Unix-like operating systems can read DOS format files.
We are always interested in hearing about people’s experiences installing SCHED on various machines. If you have problems, or even success on machines other than those listed earlier, please let us know (email to email@example.com). We would be especially interested if someone ports SCHED to a non-unix, or unix-like (eg Linux) operating system. SCHED was supported under VMS and DOS in the past and the coding style hasn’t changed, so a port to such operating systems would probably not be difficult.
A recent experience installing SCHED on a MacOSX 10.5.4 system showed the need to be careful about compiler versions. That version of OSX uses version 4.0.1 of the gcc compiler. You have to use gfortran, a Fortran 95 compiler, with gcc versions above 4.0 and g77 with lower gcc versions. PGPLOT was loaded from the Fink, as were both g77 and gfortran, and the PGPLOT was first built with gfortran. The build of SCHED only went smoothly after switching to gfortran for SCHED. There will be similar issues wherever the switch from gcc 3 to 4 occurs. For some details of my first install of SCHED on a Mac in 2003, see Appendix B.8.