So you’ve got an urgent thing to do with the telescope and Jim Palfreyman (0407882718) is using it to observe the Vela pulsar, you can’t get hold of him and you need to do your thing.
If your thing is oiling the gears or polishing the focus cabin (or other such tasks that don’t involve the receiving and recording chain), then just use vdesk to move the dish, lock it off with the key, hit the stop button, and do your thing. When finished restore the key and stop button, and observing will continue automatically. Email Jim (email@example.com) to let him know the stoppage times.
If you are doing some observing then it is imperative you follow these instructions and close down the Vela observation properly otherwise your data almost certainly will be stuffed.
log=<your file> (you will probably do this anyway for your experiment, but this is just a reminder.)
Starting a Vela Pulsar Observation
If the server is not running you need to run vncserver -alwaysshared -geometry 1280×720 preferably from the desktop.
fs (as oper@hobart)
Agilent 4.1 GHz/16 dBm
SML01 876 MHz/7 dBm
SML02 876 MHz/7 dBm
SMY01 off (can be set to 688 MHz/7 dBm if you are at the observatory and want to confirm the signals are being received using the spectrum analyser)
Channel 1 on Multifeed RCP
Channel 2 on Multifeed LCP
DAS attenuation to roughly 11 and 14. (This will be automatically adjusted later on).
DC Input to External SLD
DC Attenuation to 5 dB.
./record 2015_183 1376 set
./record 2015_183 1376 1h
./agc 2015_183 1376 (but use the date and frequency you are recording in!)
./stow set (as oper@hobart if it’s not there).
at -f fire_cal 1200
./record_fluxcal 3C353_O 2014_176 1376
It is now possible to kick off an observation in advance, even if one is running. The receiver needs to be in place, directories created, noise diode test completed, oscillators set up, DAS configured, and levels roughly set.
As an example, Vela is currently set and it is day 184 in 2015.
date; ~/jimp/velars -s -d; date; sleep 10s; ~/jimp/track vel15184
date; ~/jimp/velars -s -d; date; sleep 10s; ~/jimp/record 2015_184 1376 set
date; ~/jimp/velars -s -d; date; sleep 10s; ~/jimp/agc 2015_184 1376 19
date; ~/jimp/velars -s -d; sleep 10s; date; ~/jimp/stow set
The 10 sec sleep is just to avoid a race condition where for 1 second, vela is up and down at the same time!
check=*,-rx (for temperature warnings)
(Note that -vd and -ifd need to be adjusted depending on the error.)
The receiver at Ceduna is manually loaded by Bev. These instructions are for observing in C band (4.8 GHz).
mount /dev/sdd1 /mnt/usb1
rsync —stats —ignore-existing —remove-source-files -v -t -r /exports/xraid/Al_1/pulsar /mnt/usb1
All commands use a 10 second .ar file that live in the RDSI structure.
psrplot -p Y -j Fp -D 10/xs blah.ar
psrplot -p D -j FTp -D 10/xs blah.ar
psrplot -p D -j Fp -c subint=42 -D 10/xs blah.ar
psrplot -p D -j Fp -c subint=42 -j ‘centre cof’ -D 10/xs blah.ar
psrplot -p D -j Fp -c subint=42 -j ‘centre cof’ -c ‘x:range=(0.45,0.55)’ -D 10/xs blah.ar
psrplot -p D -j Fp -c subint=42 -j ‘centre cof’ -c ‘x:range=(0.45,0.55)’ -c ‘x:unit=ms’ -D 10/xs blah.ar
Once the data has been collected it needs to be processed. This is done using the hex cluster which is connected to the RDSI storage. But first the data has to be moved there.
Typically this is run from a vncsession onto hex0. If the server is not running type (as pulsar@hex0):
vncserver -alwaysshared -geometry 1280×720
Log onto sirius (aka mk5ce) and type:
rsync —stats —ignore-existing —remove-source-files -v -t -r /exports/sirius_internal16/pulsar/J0835–4510_S/ /mnt/rdsi/pulsar/process/MTP26M/J0835–4510_S; date
Next we need to process. Log onto a hex node (say hexb) and:
mv 2014_123 /mnt/rdsi/pulsar/process/MTP26M/hexb/J0835–4510_S
This moves the directory into a spot for hexb to process. This is not strictly necessary (i.e. all files could be in one spot) but makes things efficient when processing large amounts of data. It does require manual supervision but it is still way faster. Now start processing:
lbapsr_master.csh /mnt/rdsi/pulsar/process/MTP26M/hexb Hobart 8
This can be repeated for as many hex nodes as required.
After a directory is completed:
mv 2014_123 /mnt/rdsi/pulsar/MTP26M/J0835–4510_S
This puts it in with the rest. Now go there:
Note that in all the following commands, do NOT use a trailing / on the directory name! To move all the raw files into their own directory run:
To create .ft files in a timing directory:
To create today.ft (which is an integration of all the pulses for the day):
To create an all.tim file in the timing directory:
To run tempo2:
After deleting bad observations in tempo2, save a new .tim file in tempo2 format as fixed.tim. Save a .par file as today.par.
To create the all.spa file in the spa directory:
Note that all of these commands only run on one core. You can background them and run up to 8 on a single hex machine.
Down the track and it’s time to free up space by deleting those large lba files, type:
This will search the spa output for bright and consecutive pulses and moves those .lba files to a raw.keep directory. Once you’ve verified this command has done that to your satisfaction, copy/paste the rm -rf 2014_123/1376/raw command to delete the raw directory. Please use the copy/paste - this prevents typos and deleting the wrong directory!!
To pull out good timings of all data so far so this in the J0835–4510_S directory:
cat 2014*/1376/timing/*fixed.tim |grep -v C › allsofar_fixed.tim
Then to pull out 5000 random samples:
shuf -n 5000 allsofar_fixed.tim > allsofar_fixed_5000.tim
The use tempo2 to see it all:
tempo2 -gr plk -npsr 1 -nobs 10000 -us -grdev 20/xs -f /imports/rdsi/pulsar/MTP26M/J0835–4510_S/J0835–4510.eph allsofar_fixed_5000
To create daily.tim (which is the arrival times of all the today.ft files):
To use tempo2 to see these daily summaries (way less points to deal with and great for creating an ephemeris):
tempo2 -gr plk -us -grdev 20/xs -f /imports/rdsi/pulsar/MTP26M/J0835–4510_S/J0835–4510.eph daily.tim
Observing of the Vela pulsar (J0835–4510) is currently occurring whenever the 26m telescope is otherwise free. Vela is visible 17 hours a day (LMST 00:00–17:00) and will generate 4 Tb of data if a full day is observed. This is being stored on rdsi. In the past the raw “.lba” files were processed and discarded. We now plan to keep them so further processing can be conducted on interesting events.
This Vela pulsar collection is currently by far the largest single pulse archive in the world. And expanding. There is plenty of scope for further study on the data collected. If this interests you then please contact Jim Palfreyman (firstname.lastname@example.org).
Old notes - this may no longer be accurate
Mt Pleasant is equipped with a dual-pol, 64 MHz bandwidth baseband recorder and a 48 core cluster that can be used together as a pulsar coherent dedispersion system. The telescope signal is routed into the ATNF data acquisition system (DAS) in the same way as for VLBI or correlator observations. The output of the DAS is fed into the eVLBI recorder via the “BG3” cable and the eVLBI software (“vsib_record”) is used to record data to “hovsi” which is connected (via a dedicated ethernet cable) to the 24 Tb host “sirius”.
The data can be processed at any time, during or after the observations. A set of scripts have been written to automate the transfer and processing of baseband data for pulsar observations. When running, these scripts will copy data from the XRaid to the Origin 3400 one file at a time and run the coherent dedispersion and folding software (“dspsr”) on each file, using an ephemeris from the collection kept in $TZPAR. The Origin 3400 originally had 24 processors but one of the blades developed a fault before it was given to the observatory and will not run reliably. It is best to leave this blade turned off (there is a red sticker over the power button) or the whole machine will crash on average once a day. The remaining blades have a total of 20 processors. At best (for low dispersion measures) this allows processing at a rate roughly 1/3 real-time. There is 1GB of memory per processor, which is usually enough but can be insufficient if very high-resolution processing is attempted (single pulses with lots of frequency channels and phase bins for example).
Processed files are transferred across the network to a TPAC-based mass storage device that is mounted as /imports/tpac/pulsar on the radio astronomy server, ares.
When using vsib_record to take pulsar data, please ensure that the DAS is running the profile called PSR64_N.PRO. This profile disables the automatic gain control system, which is essential when observing bright pulsars (otherwise, the AGC tries to remove each incoming pulse and you end up with a large artificial dip on the trailing edge of the profile). This profile operates the DAS in 64 MHz mode, which requires a special cable (the BG3 cable) to interface between the correlator ports on the DAS and the input to the VSIC converter card. This is quite different to the “normal” eVLBI mode of operation where the S2 data output port it used. The vsib_record program should be run with the arguments “-m 2 -w 64″ to ensure correct recording.
Data can be recorded to any of the mass storage devices connected to the eVLBI machine, “hovsi”, in a subdirectory called “pulsar”. For example, to use the first set of XRaid disks, record to “/data/xraid0_0/pulsar”. Within the pulsar directory, you should construct a series of nested directories named after the source, day of year and observing frequency. This directory structure is critical. At the moment, no information regarding the telescope coordinates or system setup can be stored in the baseband data files produced by vsib_record, so the pulsar processing software reads all the information it needs from the names of the directories in which the data are located. You should start with the source name in J2000 format. For the Vela pulsar this would be “J0835–4510″. Inside the source directory you should create one (or more) directories named for the date, in the format “YYYY-DOY”. For example, 2007_183. Inside the date directory, you should create directories named after the observing frequency in MHz. Files should be recorded inside these frequency directories.
Once data is flowing to a storage area on hovsi, you can begin processing it with the Origin. See Aidan for details as the system is still somewhat experimental.
ifconfig eth0 192.168.1.2 (unlikely to need this)
calu -m sam26m (and press return when prompted with rakbus.)
samtest -c 5 -d 0.5 -i 0 -n 1 -s 120 -f 30 (followed by sam26m but DON’T press return yet!)
vsib_record -m 2 -w 64 -f 10s -t 90s -o CAL_J0835–4510 (but press Return on samtest first, then this one.)