Software for VLBA operation with the GBT.

F.Ghigo -- NRAO-GB, Oct 19, 2004, Sept 2005.
revised Aug - Sept 2006
more revised October 2007
revised again March 2009

Some relevant links
VLBI General Info Operator's checklist Project Summaries

Introduction

The intent of the GBT-VLBA system is to make the GBT appear to the user (and to the VLBA operator) very much like one of the standard VLBA stations (although of course with 16 times the collecting area!).

When the GBT is used for VLBI observations, it uses the same VLBA data aquisition system that is used at all VLBA sites. But at the GBT, the VLBA station computer controls only the DAR, Formatter, Tape Recorders, and Mark 5 disc recorder. It does not control the antenna and IF system. The latter are controlled by the GBT M&C system driven by the ASTRID user interface.

Schedules for VLBI experiments are prepared by the user and deposited on the "aspen" server in Socorro. We have to retrieve these schedules and convert them into the right form for the GBT.

Status data from the M&C system must be passed to the VLBA station computer so that they are recorded in the VLBA log files, which are sent to Socorro.

All these programs are intended to be run by the user "gbvlbi". Log in as "gbvlbi" to run any of these VLBI-related programs.

Note: the use of tape recorders has been discontinued, as of early 2007. So ignore any mention of tape recorders in the following. All recording is done on Mark 5 disk recorders now.

Overview of the Hardware

Changes October 2007 due to dynamic scheduling.

Overview of the Software

The system is diagrammed in the flow chart. The things outlined in ovals are the software components unique to the GBT-VLBA communication system, which are not standard parts of the GBT software or the VLBA software systems. Most of the VLBA communication software runs on the VLBA Host, which at the moment is "Spock".

Clicking in various parts of this diagram will link to the explanations.

For Those who do not like a graphical index, here is a non-graphical index.
Topic Description
retrieve Retrieve Schedule Files
keyfile "Key" file
schfile "Sch" file
crdfile "CRD" file
vlbprep Handy do-all script
webpage Project Web Pages
obstx OBSERV.TX job schedule.
convert Convert to Astrid script.
gbtobs Astrid observing interface.
M&C GBT Monitor system.
status Status Demon
display Status Display
remote commands VME remote commands
VME computer VME station computer
customization custom station software
screens SCREENS interface package
logdata station log data
logging Sending Log Data to Socorro
viewer Local viewer for log data.

October 2007 Changes for dynamic scheduling.

Due to the new dynamic scheduling of VLBI experiments, The PI or analysts will generate two schedules for the experiment, one for the primary date, and one for the alternate date. The PI must decide which of the two schedules will run, and makes that decision at least several hours before the primary schedule would start (often the day before). If the decision is made for the primary date, everything happens just as it used to. If the decision is made to run on the alternate date, then what the operator needs to do is to run a script, (note: "setalt" is now obsolete) "obset", described below, which will make the OBSERV.TX file refer to the alternate schedule. This must be done before the primary schedule would have run. Also, in running Astrid, the operator must select the alternate observing blocks.

To support these changes, the VLBA operators have added a new directory on the Aspen website, named [projcode]alt/ in which the alternate schedules will reside. Here at Green Bank, we have added an alt/ subdirectory in the ~gbvlbi/obs/ directory into which the alternate schedules will be put.

To support the dynamic scheduling, the following programs have been modified, and the descriptions of these programs have been appropriately amended.

fetchvobs now will look for a directory with "alt" in its name, as well as the regular project directories on Aspen. It will retrieve files from the "alt" directory on Aspen and put them into the local "alt" directory here in Green Bank. The "crd" and "sch" files will be given and extension of ".gba" instead of the usual ".gb".

vlbprep will process files both in the current directory and in the "alt" directory. Astrid scheduling blocks created in the "alt" directory will have "alt" in their names. Note that vlbprep will run in whatever directory you are in. So you must always be in either the ~gbvlbi/obs/ or the ~gbvlbi/obs/incoming/ directories.

obset will ask for input from the user and will set up the OBSERV.TX file to point to the alternate project for a project indicated by the user.

vlbastrid now has a new option ("-alt") which will put an "alt" in the names of the Astrid files that it generates. Normally one does not run vlbastrid directly: it is done as a result of running "vlbprep."

Retrieve Project Files from Socorro

to run this process : ~gbvlbi/bin/fetchvobs
usage: fetchvobs [mmmyy] [projcode]
mmmyy is month and year, for example: apr06
if no arg, fetch files for current month.
if projcode is given, fetch files for only that project
source code : ~gbvlbi/codelinux_mk5/python/fetchvobs.py
It retrieves files into whatever your current working directory is. We normally run fetchvobs in the "/users/gbvlbi/obs/incoming/" directory.

Web Link to Aspen server .

fetchvobs retrieves files from the VLBA schedule server, "aspen", for the specified month. It finds all the projects that have "..crd.gb" files, meaning that the GBT is involved.

For each GBT project in the specified month, it downloads the following files:

  • ...key
  • ...sch.gb
  • ...crd.gb
  • and the ..contact file, if it exists.

    Modifications for dynamic scheduling, October 2007
    fetchvobs now will look for a directory on Aspen with "alt" in its name. It will retrieve files from the "alt" directory on Aspen and put them into the local "alt" directory here in Green Bank.

    Maintenance
    fetchvobs depends on the details of the directories and file names used on "aspen", also of course the name "aspen", and the web URL. So if any of these things change, the program has to be modified.

    Future extensions
    This could be extended to retrieve schedule files from the European server in Bologna. That server is not used very often for GBT projects, so at the moment we just retrieve those projects by hand.
    Similar comments apply to geodetic projects that would be downloaded from Goddard Space Flight Center.

    back to index

    "KEY" file

    The astronomer creates a "key" file for any VLBA experiment. This file specifies the sources, frequency setups, and schedule for the run in a compact and user-friendly way. The instructions may be found in the     SCHED USER MANUAL. The Sched programs are maintained by Craig Walker in Socorro. The user runs the Sched program to process the "key" file. The outputs include a "crd" file and a "sch" file, described later.

    The user normally submits the "key" file to the VLBA analysts or operators who use Sched to generate the "crd" and "sch" files and deposit them on "aspen".

    To see an example, go to the directory ~gbvlbi/obs/ and look at any file with a ".key" extension.

    "SCH" file

    The "sch" file presents the schedule of the VLBA experiment in a convenient form for the telescope operator.

    To see an example, go to the directory ~gbvlbi/obs/ and look at any file of the form "[projcode]sch.gb".

    "CRD" file

    The "crd" file is used by the VLBA station computer to direct the data acquisition and recording. At the GBT, the Astrid script files are generated from the "crd" file, and the "crd" file is also used by the status demon. Thus this is the most important file as far as we are concerned.

    To see an example, go to the directory ~gbvlbi/obs/ and look at any file named "[projcode]crd.gb" or "[projcode]cr.gb".

    back to index

    VLBPREP: handy do-all script

    ok, so it really doesn't do it all.
    To Run: ~gbvlbi/bin/vlbprep
    Source: ~gbvlbi/codelinux_mk5/python/vlbprep.py
    and ~gbvlbi/codelinux_mk5/python/vlbpreplib.py

    This is a handy python script that

  • looks at all the "[projcode]cr.gb" or "[projcode]crd.gb" files in the current directory,
  • creates the OBSERV.TX file, and
  • runs "vlbastrid" on each of the "crd" files to create the Astrid scheduling blocks.
  • renames the "..crd.gb" files to "..cr.gb" or "..c.gb" if necessary.
  • creates a summary file "projid__sum" which is a concatenation of all the Astrid scheduling block files for the experiment.

    vlbprep modifications, October 2007
    Because of the new dynamic scheduling of VLBI experiments, the PI/analysts will generate two sets of "[projcode].crd" files for each experiment. The "fetchvobs" script will look for the alternate "crd" and "sch" files and will put them in the local "alt/" directory. vlbprep will process files both in the current directory and in the "alt/" subdirectory. In this regard, a new script, "obset" is used for setting the alternate schedules in the OBSERV.TX file.
    Note that vlbprep will affect the files in the current directory. So you should be in either the ~gbvlbi/obs/ or the ~gbvlbi/obs/incoming/ directory. It looks for "alt" files in an "alt/" directory in the current directory.

    vlbprep modification, Nov 2008
    By default, vlbprep will run version 3 of vlbastrid, actually its named "vlbastr3". The new vlbastrid is described     below. If for some bizzarre reason one wants to run the old version one must say "vlbprep ver2".

    Maintenance: Probably none.

    Future development:
    This should have the capability of adding the scheduling blocks into the Astrid database. At the present, one must do this by hand.
    Also, this could automatically generate the summary web page for the experiment.

    OBSET: ask the user to select an alt shedule, if needed, and create the OBSERV.TX file.

    Added as of October 2007. (formerly: setalt) Revised Nov 2008.
    To Run: ~gbvlbi/bin/obset
    Source: ~gbvlbi/codelinux_mk5/python/obset.py
    and ~gbvlbi/codelinux_mk5/python/vlbpreplib.py
    obset is run with no arguments. It looks for alternate projects in the ~gbvlbi/obs/alt/ directory. If it finds some, it asks the user which one to use. After the user makes the selection, it generates the OBSERV.TX file in the ~gbvlbi/obs/ directory. Note that it does not matter which directory you are in when you run obset. If there are no projects in the obs/alt directory, then obset creates an OBSERV.TX file with only the primary projects.
    For example, the OBSERV.TX file resulting from "obset" might be : 
    alt/bb240acr.gba 2007oct01 17h57m 2007oct05 04h04m
bb240bcr.gb 2007oct05 04h04m 2007oct06 22h20m
gl030crd.gb 2007oct06 22h20m 2007oct19 17h04m
gb060acr.gb 2007oct19 17h04m 2007oct24 08h35m

    Project Web Pages

    The project web pages are helpful for the operator's setting up for each experiment. They also are the "archival" information about all experiments that have been run on the GBT.

    There are 3 types of pages:

  • 1. Summary of upcoming projects.
  • 2. Example of page for a project.
  • 3. Summary of past projects.

    Modifications as of October 2007:
    item number 2 (page for each indivual experiment) has been discontinued -- too much work!

    Maintenance
    All these are created and maintained by hand.

    Future developments
    The page for the individual experiment could probably be created automatically. It has information that is drawn from the "crd", "sch", and "key" files.

    OBSERV.TX file

    This file is a standard part of the VLBA system. It lists a queue of project "crd" files and gives the start and stop times of each. These normally are placed in the ~gbvlbi/obs/ directory.

    OBSERV.TX is read by the VLBA station computer ("vlbagb" in the case of Green Bank) to tell it what schedules to run when. If one changes the OBSERV.TX file it is necessary to re-boot the station computer.

    An example: 
    bu031dcr.gb 2006aug04 17h19m 2006aug07 00h05m
bk127dcr.gb 2006aug07 00h05m 2006aug13 16h35m
bf088ccr.gb 2006aug13 16h35m 2006aug30 03h35m
    The scripts "vlbprep" and "obset" look at the start and stop times of all the "crd" files in the current directory and creates the OBSERV.TX file. The start time of each schedule is the stop time of the previous schedule. The stop time of each schedule is 5 minutes past the ending time in the "crd" file.

    Modifications as of October 2007
    Due to the new dynamic scheduling of VLBI experiments, The PI or analysts will generate two schedules for the experiment, one for the primary date, and one for the alternate date. The PI must decide which of the two schedules will run, and makes that decision at least several hours before the primary schedule would start. If the decision is made to use the alternate schedule, then the OBSERV.TX file must be modified to point to the alternate file, which is in the "alt" directory. This re-creation of OBSERV.TX is done via the script     obset.

    A typical example of such a modified OBSERV.TX file: 
    alt/bb240acr.gb 2007oct01 17h57m 2007oct05 04h04m
bb240bcr.gb 2007oct05 04h04m 2007oct06 22h20m
gl030crd.gb 2007oct06 22h20m 2007oct19 17h04m
gb060acr.gb 2007oct19 17h04m 2007oct24 08h35m

    back to index

    VLBASTRID: Convert VLBA schedule to Astrid Observing Blocks

    To run : ~gbvlbi/bin/linux/vlbastrid
    to run new version: ~gbvlbi/bin/linux/vlbastr3
    source code : ~gbvlbi/codelinux_mk5/vlbastrid/vlbastrid.c
    and ~gbvlbi/codelinux_mk5/vlbastrid/vastlib.c
    new version code: ~gbvlbi/codelinux_mk5/vlbastrid/vlbastr3.c
    to make : cd ~gbvlbi/codelinux_mk5/vlbastrid/
    make vlbastrid
    cp vlbastrid ~gbvlbi/bin/linux/
    make new version : cd ~gbvlbi/codelinux_mk5/vlbastrid/
    make vlbastr3
    cp vlbastr3 ~gbvlbi/bin/linux/
    Usage: vlbastrid schedcrd.gb [-mbbc] [-lump] [-alt]
    in which "schedcrd.gb" is the input schedule file.
    Usage, new version: vlbastr3 schedcrd.gb [-alt] [-d]
    in which "schedcrd.gb" is the input schedule file.
    "vlbastrid" reads in the "crd" file and generates a series of scheduling blocks for Astrid. The scheduling blocks are written into files having an extension ".turtle". A ".._setup.py" file is generated which contains all the configuration setups that may be required by the schedule. Look in ~gbvlbi/obs/ for examples of these files.

    There is a fair amount of documentation in the code in vlbastrid.c.

    One should note that special astrid definitions (such as "vtrack") are used that are permanently resident in "~gbvlbi/obs/vlbadefs.py".

  • The initial block does an "AutoPeak" or "AutoPeakFocus", whether or not the observer calls for it.
  • If the observer calls for a peak during the schedule, a new block is generated which runs a Peak and/or Focus.
  • Normal scans are run using a "vtrack" command in the scheduling blocks which gives the stop time of the observation.
  • vtrack allows the system to skip down the list to the next observation to be run. i.e., its ok to start the schedule late.
  • A new scheduling block is issued whenever the user changes frequency setups or changes receivers.
  • Turning the phase cals on or off, or enabling/disabling the noise cals are done with special functions and do not require re-configuration. 

      Note Special Case for Comets and other Moving Objects
     This is not standardly handled by vlbastrid.  Instead,
     you have to run "geteph" to get the ephemeris info from 
     a "crd" file into an Astrid ephemeris catalog.

    Modifications as of October 2007. To support the dynamic scheduling, vlbastrid now has an optional command line argument, "-alt". If "-alt" is specified, the astrid scheduling block files will have names that contain "alt". Thus these files can be easily identified as referring to the alternate schedules. Normally the user does not run vlbastrid directly, but instead runs "vlbprep", which takes care of making sure that when vlbastrid runs on the alternate schedules it is run with the "-alt" option.

    Modifications as of Nov 2008: vlbastr3 The new version (or version 3) is now standard. In this version, the case of moving sources such as comets are handled properly, so you can ignore the "special case for comets...", above. Also, in the new version, there are no separate pointing/focus scheduling blocks for every point/focus. These are imbedded in the script, using the new function, "vpeak", which is given the stop time so it can skip the peak if its time is passed. All changes of configuration are handled in the new versions of the python functions "vtrack" and "vpeak". The only situation that causes new scheduling blocks to be generated is changing of receivers.
    This version uses a new set of functions in the file, "newvlbadefs.py".

    Maintenance and future development.
    The "crd" files can specify a wide variety of observing modes and scenarios. "vlbastrid" only handles those cases that so far have been used in projects with the GBT. Hence one must be on the lookout for observing runs that call for something that vlbastrid does not know about, and be ready to modify it to handle a new case.

    back to index

    GBT Observing System -- Astrid

    This is the standard user interface to the GBT, so no need to say anything about it here.
    Refer to:     Astrid Users Guide

    back to index

    GBT monitoring data

    There are several bits of data that need to be sent to the VLBA station computer so that it can in turn be put into the VLBA log files which end up in Socorro.
  • Antenna Coordinates, i.e., is the antenna on source or not?
  • Clock correction, from SiteTime-OnePps-OnePpsDeltas.
  • Weather Data: temperature, dewpoint, pressure, wind speed, and wind gust.
  • Cable length, from the round trip phase monitor, (Site-Time-Rtpm140-Rtpm)

    The sampling of the monitoring data and the sending of them to the VLBA station computer are described in two sections below: "Status Demon" and "Remote Commands".

    back to index

    Status Demon

    To run : ~gbvlbi/bin/stopgvstat
    source code : ~gbvlbi/codelinux_mk5/vlbastrid/vgstatus.c
    ~gbvlbi/fits/vfitsdat.c

    The programs of the Status Demon access the monitoring data in various ways and send them to the VLBA station computer. vgstatus and vfitsdat normally run on the machine "spock".

    This consists of two programs that interact with each other.

  • vgstatus.c -- connects to the gbtstatus database, reads telescope RA/DEC, and wind speed.
  • vfitsdat.c -- reads recent FITS log files, reads clock correction, round-trip phase, weather data.

    vgstatus and vfitsdat send status info to the station computer. Refer to Remote Commands for details.

    vgstatus and vfitsdat write status info into files ~gbvlbi/obs/logs. Also, vgstatus writes a web file giving timely status info onto the page: http://www.gb.nrao.edu/GBT/setups/vlbsetup/GBTVLBAStatus.html

    The schizophrenic nature of this status demon results from
    a) not all the data is available in one place: the gbtstatus database has telescope position, temperature and wind speed, which we need to sample once a second.
    b) the clock correction, round trip phase, and weather data other than windspeed are not all available in the gbtstatus database, and do not need to be sampled very fast, but can be read out of the FITS log files every minute or so.
    c) Demons tend to hang up and have to be restarted.

    How they interact:

  • "vgstatus.c" runs continuously and samples the gbtstatus database every second.
  • "vfitsdat.c" is started every 3 minutes by a crontab.

    "vfitsdat" checks for the existence of a file "~gbvlbi/obs/logs/.vgstatusstatus". If this file does not exist, that means that "vgstatus" is not running, and so it launches "vgstatus".

    "vgstatus", when it starts up, creates the ".vgstatusstatus" file. If it notices that the file no longer exists, it terminates itself.

    The operator is advised to execute a program called "stopgvstat" which simply removes the ".vgstatusstatus" file before the start of a VLBI run. That causes "vgstatus" to terminate. Then the crontab runs "vfitsdat", which starts "vgstatus" again.

    Onsource status
    "vgstatus" reads the "crd" file, checks the RA/DEC and compares to the position in the "crd" file for the current time to see if the telescope is at the correct position. The onsource/offsource flag is sent to the VLBA station computer, as described below under "remote commands".

    wind gusts
    "vgstatus" samples the wind speed once per second from the gbtstatus database and accumulates a maximum speed over a 15 minute period. This is written to a file: ~gbvlbi/obs/logs/wgust.dat
    This file is later read by "vfitsdat".

    Maintenance
    The reading of the gbtstatus database depends on knowing the database name, password, host machine, and names of the parameters in the database. If any of those things change, the software will have to be modified. If any of the FITS file formats change, that also will require software changes.

    Future developments
    We may re-write to avoid using the gbtstatus database at all by using Amy's "wxdemon.py" which accesses the samplers directly.
    (see ~gbvlbi/codelinux_mk5/python/wxdemon.py)
    We may be able to use this method for all the monitor data and not need to look up some things in the FITS files, and other things in the gbtstatus database.

    back to index

    GUI status display and web status display.

     Web Page Reference : http://www.gb.nrao.edu/GBT/setups/vlbsetup/GBTVLBAStatus.html

    This web status display has replaced the TCL script "gvstat", although gvstat still exists and will run, but doesn't have as much information as the web page.
    This web page is generated by the status demon, "vgstatus.c", as described above.

    gvstat:
    To run : gvstat
    source code : ~gbvlbi/tcl/gvstat.tcl

    This TCL script simply displays the contents of two files, ~gbvlbi/obs/logs/vgstat.txt and ~gbvlbi/obs/logs/vstat.txt, in a tcl window, providing a handy display of the GBT monitor data that is being sent to the VLBA station computer. It updates the display every ten seconds.

  • vstat.txt -- is written by "vfitsdat"
  • vgstat.txt -- is written by "vgstatus"

    Maintenance and Future developments
    We could use a web page display instead of TCL. -- well, I guess this has happened!

    back to index

    Remote Commands: sending status data to VLBA computer.

    To run : rcmd [command] [params]
    source code : ~gbvlbi/codelinux_mk5/rcmd.c
    This is a standard part of the VLBA software system. We have added special commands to the repertoire to send status data to the VLBA station computer.

    Onsource Command (sent by "vgstatus") :

  • rcmd onsource 1 gb [GBT is on source]
  • rcmd onsource 0 gb [GBT is off source]

    Other commands are sent by "vfitsdat" :

  • rcmd gpsdata nnnn nnnn.nnnn gb [send clock correction]
  • rcmd gbtrtp nnnn.n 0 0 1 gb [send round trip phase]
  • rcmd gbtwx temp dewp pressure wvel wdir wgust snum [send weather data]

    Maintenance
    This program is maintained by the Socorro software people. If we want to make any changes, we need to coordinate with them.

    back to index

    VME Station Computer

    The VLBA station computer for the GBT is named "VLBAGB". It is a VME single-board. At the VLBA sites, it monitors and controls everything. At the GBT it only monitors and controls the data acquisition rack and recorders.

    All, or most anyway, of the local customization is done in the vxWorks startup file, located in ~gbvlbi/code_mk5/startup.gbt.
    That file tells the VME machine the IP addresses of itself, the host machine, and the Mark 5 computer. Also where to find the directory for the observing files (OBSERV.TX and ...crd.gb), and where to put the log files.

    Communication :

  • NFS mount -- it has a filesystem of the host machine "spock" mounted. When it boots up it gets its system software from the host. It also loads all the station software from the host. The host file system is where it finds the OBSERV.TX file and the "crd" files, i.e, the observing schedules. Also, a local copy of the log files is written to the host computer.
  • screens socket : it runs a demon which allows the external process "rscreen" to communicate over a socket. This provides a user interface using "curses" displays.
  • logger socket : the log data is sent via a socket to a log host, which in our case is the machine "jansky" in Socorro.
  • rcmd socket : it runs a demon which accepts commands from a remote host.

    Maintenance
    This program is maintained by the Socorro software people. If we want to make any changes, we need to coordinate with them. Refer to     station software customization, below.
    They update the system maybe once or twice a year, at which time we copy the new software to the local host computer, from which the VME machine uses it.
    Hardware maintenance: Nathan Sharp and John Ford.

    back to index

    SCREENS user interface

    To Run: rscreen [station]
    for GB : rscreen vlbagb
    Source Code: ~gbvlbi/codelinux_mk5/rscreen.c
    If logged in as user "gbvlbi" you can run the handy script "rs" to bring up the rscreen interface for vlbagb.

    This is the user interface to the VLBA station computer. It provides "curses" displays that allow a user to monitor and control all the things that the station computer can control.

    The user runs the "rscreen" program on the host computer, which communicates with the station computer over a socket.

    For instructions on rscreen, run it and click the help button.

    Maintenance
    This is a standard part of the VLBA software system. It will probably never change.

    back to index

    Log Data

    The log data is basically a stream of binary c-structures. The station computer writes to the log file every minute or so. The log data goes to two places: 1) is a local copy written over the local internet to a file on the host computer (at the moment this is "Spock"); 2) a remote copy written over a socket to the "log host" on a machine in Socorro.

    Local customization does not require any code changes to the standard VLBA software. The specification of where the log file goes is done in the startup script (startup.gbt) that the station computer runs when it boots up.

    On the Green Bank system, the local log files are put into the directory ~gbvlbi/mdata/MDA/

    Maintenance
    This is a standard part of the VLBA software system. It will probably never change.

    Sending Log Data to Socorro

    The "log host" runs a demon called "netmon" which receives the log data over the socket from the station computer. No special customization for Green Bank is required. All we do on our end is to make sure the station computer is on a network that can be seen from Socorro and that the name and IP address of the log host are set in the startup script.

    Maintenance
    This is a standard part of the VLBA software system. It will probably never change.

    back to index

    Log Viewer and Plotter

    To run : seelog ⟨logfilename⟩
    source code : /users/gbvlbi/codesun/seelog.c
    plotting : /users/gbvlbi/glish/plog.g

    seelog.c reads a log file and dumps the information to an ascii file. This runs only on Solaris machines because the byte order on Solaris is the same as on the VME station computer.

    plog.g runs a glish application with GUI interface that lets one plot the system temperatures and phase cals from the log data.

    Maintenance and future developments
    The VLBA operators have a suite of programs for displaying and plotting the log data; we should just get their programs working here in Green Bank.

    back to index

    VLBA Station Software customization

    There are several local modifications to this code for the GBT. Since the GBT system does not control the antenna or the LO system, several programs and checks must be disabled. We use "rcmd" to send GBT status information to the station computer, so modifications to several routines are done to accomodate this.

    All the GBT-specific code is installed in the standard VLBA station code, with conditional statements in the code to detect if the station is the GBT and to do GBT-specific things in that case. Any changes to the station computer code or host code needs to be coordinated with the programmers in Socorro.

    vxWorks startup script

    The startup script is referenced by the vxWorks boot-up prom, and is executed after the boot up and loading of the vxWorks kernel. At the moment, this script is in ~gbvlbi/code_mk5/startup.gbt Several customizations are done in this script. Maintenance
    Any changes to the Green Bank file system, such as relocating or renaming "filer", might require changes to the startup script.
    For example, the mount command for "filehost" is:
  • nfsMount "filer", "/vol/vol2/users/gbvlbi/obs", "filehost"
    If the "filer" machine name changes, or if the hardware path "/vol/vol2/users" changes, then this command, along with "netDevCreate" and "hostAdd" would have to change accordingly.

    back to index