At each observatory you need to run the
obs.pl program. This connects to the correlator processors at Parkes and copies the requested data down the network.
Obs.pl should be run remotely by who ever is running the fringe test, as they sometimes hang and have to be restarted. This should be run after the correlator processes are started. Once you have logged onto the recorder PCs, you need to cd to the directory where the data is being recorded then run obs.pl. If the recorder is currently been run via
cdisko or other programs which use “recorder_server”, then an alias “
recdir” is setup which will automatically change to the correct directory. Usage will normally be something like:
> recdir > obs.pl
On Mark5 systems you will have to “
cd” to whatever directory the Mark5 is dumping the data.
If disk recording is moved to a different directory,
obs.pl will have to be stopped and restarted in this new directory.
The recorders are running on the following machines and usernames. Note if remote recording is being run, you need to log onto the machine where the data is being written to disk NOT the machine where the data is received from the telescope. You can only connect via ssh.
|Katherine#3,4#||<addme> .||observer||~/vbs .||
#1# Log onto hovsi first then use
rtfc-tunnel to ssh with appropriate tunnels setup
#2#RTFC does not work well to Hart directly. Try the following:
sshhartvdif cd data <Check out what files have been dumped> sharethart <file>
This is not quite right yet
cd /data/hart gethart hart obs.pl
Manual mounting of data via vbs_fs utility is required, Then you can fringe test any time range you need
The following can be done until RtFC supports this automatically. Note this needs to be redone very time you want newer data than was selected earlier (ie the links etc are static).
fusermount -u /mnt/vbsRFTC # May not be required if first vbs_fs -I 'v*' /mnt/vbsRTFC cd vbs \rm -f * # Run with caution! Not strictly necessary every time ln -s /mnt/vbsRTFC/* . # Or (e.g.) ls -s /mnt/vbsRTFC/v255* obs.pl -nofilter
Katherine DBBC3 is not supported by Sched. You will need to manually create vexfile to match setup. Note there are usually multiple independent streams of data. Usually it will be 2 streams, one for each pol. The bandwidth will probably not match other stations - e.g. probably 32 MHz channels. Also There is currently easy way to select which pol RtFC chooses.
Note that at Parkes we also record data onto pam-store-ext. In such cases you need to run
obs.pl on the machine where the data is being recorded - see the note below.
rtfc_obswin.csh will start up 6 xterms and log into the recorder PCs. If you have ssh passphrases setup, you will not need passwords.
The following environment variables need to be set (or added to existing paths)
|Optional, defaults to localhost|
|Optional, defaults to localhost|
|E.g. 'At', defaults to 'Tt'|
|'ATCA Phased array', defaults to 'Test Antenna'|
If you are recording to a remote recorder you need to ensure RTFC_ANTID (and RTFC_ANTNAME) are set. For remote recorders which generally only record data from a single teleacope this will normally be setup in the login scripts. cave-store can record data from Mopra and ATCA. Aliases have been setup “mopra” and “atca” to setup the environment. E.g.:
> atca > obs.pl
Normally if the telescope IF spectrum is inverted, a flipped DAS profile should be used. However for 64 MHz recording the spectrum cannot be “flipped”. If you know or suspect the band is inverted you can run obs.pl with the “-invert” option and it will flip the data for you.
> obs.pl -invert
Obs.pl supports Mark5B recording, as long as the “
mark5access library and utilities are installed and accessible. Note this depends on the VLBI schedule having had explicit fringe test times added. Transfer times from Hartebeesthoek are terrible slow - usually it is faster to transfer the file by some other means then run
obs.pl on a local machine.