Running GUPPI With Astrid
This page describes the status of observing with GUPPI using Astrid as of 21 Sept 2009 (the initial release).
With the new release of the Astrid control of GUPPI, the key thing to remember is that you set everything
commands in astrid. Data is then taken by running an Astrid scan. For the overwhelming majority of pulsar observations that will simply mean running a
command on your source of choice.
A Well Documented Example Configuration
The following shows a scheduling block to configure GUPPI to take S-band search-mode data. All of the available parameters are shown, even though not all of them are used for this configuration. For instance, since this is a search-mode observation, none of the
parameters are used. There are three types of GUPPI observations:
search Which is "normal" search-mode data, meaning writing spectra rapidly to disk. Data are written in PSRFITS search-mode format and can be analyzed using SIGPROC and PRESTO.
fold Which is fold-mode data, meaning folding data at a known pulsar ephemeris modulo the pulse period for each spectral channel. Data are written in PSRFITS fold-mode format and can be analyzed using PSRCHIVE.
cal Which is a special-case of fold-mode data, where the 25 Hz pulsed cal signal is folded and saved. It can be used for flux and polarization calibration and is analyzed with PSRCHIVE. Cal scans are very easy now (and the configure blocks themselves turn the cals on and off so you won't forget) and I highly recommend that people start using them, if only for sanity checks of the system. (you can view cal scans using the PSRCHIVE commands:
pav -X filename,
pav -SFT filename, or
psrplot -pC filename. Each shows a slightly different view of the cal file.)
# An example well-documented S-band "search"-mode script
# usually 'Rcvr_342', 'Rcvr_800', 'Rcvr1_2', 'Rcvr2_3', 'Rcvr4_6'
receiver = 'Rcvr2_3'
restfreq = 2000.0, 2000.0 # in MHz. Must have 2 identical freqs
obstype = 'Pulsar'
# talk to Scott if you want 'GUPPI/GASP' or others as well...
backend = 'GUPPI'
pol = 'Linear' # C-band and below are native 'Linear'
ifbw = 0 # 0 for >100MHz BW modes, 80 for 100MHz.
bandwidth = 800 # in MHz. 100, 200, or 800 currently
tint = 64e-6 # sample time in seconds (very flexible)
swmode = 'tp_nocal' # 'tp' for cals, 'tp_nocal' for no cals
noisecal = 'off' # if no cals, set to 'off', else 'lo'
# The following are boilerplate until 'guppi' section
# You should probably not change them...
swtype = 'none'
swper = 0.04
swfreq = 0.0, 0.0
nwin = 1
deltafreq = 0,0
vlow = 0
vhigh = 0
vframe = 'topo'
vdef = 'Radio'
# -- GUPPI specific params -- #
# obsmode can be 'search', 'fold', or 'cal'
guppi.obsmode = 'search'
# numchan can be a power-of-two between 64 to 4096
guppi.numchan = 2048
# polnmode is 'full_stokes' or 'total_intensity'
guppi.polnmode = 'total_intensity'
# scale should be set in first config block and
# tweaked while taking data and viewing with guppi_monitor
guppi.scale = 9.0
guppi.outbits = 8 # Currently only 8 is available
# Folding specific params -- not needed for cal or search
guppi.fold_dumptime = 10 # in sec
guppi.fold_bins = 256 # number of bins in profile
# Make sure that the parfile exists!
guppi.fold_parfile = "/users/sransom/parfiles/1713.par"
# Top level disk where data will be written
guppi.datadisk = 'data2' # 'data1' or 'data2'
Most of the parameters are self explanatory, however, a few need some further explanation.
tint The integration time for each spectra is set by adjusting the
acc_len param as described in the GUPPiUsersGuide. The values for
acc_len can vary from 2 in special cases (more typically 4 or 6) up to 1024 for each BW setting of GUPPI (100MHz, 200MHz, or 800MHz, currently). The formula is (in sec):
bandwidth. The fastest limits are based on writing <200MB/s to disk, while the slowest limits can be a few tenths to several tens of milliseconds depending on the
bandwidth and the number of channels
ifbw This parameter must be set to 80 (MHz) when using the 100MHz bandwidth modes as the GBT currently does not have 100MHz bandpass filters. Also, it is highly recommended that it is set to 0 when using other modes as that will prevent previously set values of
ifbw from giving you strange bandpasses.
cal observations, this is how much we will integrate the pulsar (or cal) before dumping a set of profiles to disk. It must be shorter than the scan duration that you set via the
guppi.datadisk This is the top-level directory (i.e. RAID array, 'data1' or 'data2') where your data will be stored. It will go in a subdirectory called
/guppi.datadisk/observername/projectID/date/. The data will be owned by
monctrl and so you will not be able to remove it -- that means ScottRansom will bug you mercilessly until you process your data!
Setting the Levels for GUPPI
The trickiest thing currently (and this will change, once the balancing modification request is tackled by the GBT software group) is getting the input levels and the internal GUPPI scaling parameters set so that the output levels are correct. We handle this by using a mix of old-style expert-user commands (see GUPPiUsersGuide
) as well as a fake scan or two by Astrid.
When you observe using GUPPI with Astrid, you must first make sure that you have several xterm's open on beef where you setup the GUPPI environment using
depending on your shell.
In one of them, monitor the GUPPI shared memory buffers as before using
. The bottom of that screen will tell you if you are taking data (lots of numbers changing) and the top of the screen shows all of the key GUPPI parameters.
Before you attempt to balance the system, you must first configure the system. Do that by running a GUPPI config block with receiver, center frequency, and bandwidth settings as appropriate for your session (we recommend using a 'cal' mode block) which will cause data to begin flowing internally through the GUPPI hardware. Then use the astrid
command to slew to your source of interest, and finally, balance the system with the astrid
command. All of these things can be done in a single astrid scheduling block. You can then run the
program from the beef command line to see how much to change the Convertor Rack modules CM4
(note: those used to be CM1 and CM5!). As long as you are not running a scan, you can re-run
and iterate the CM attenuator values until you get proper levels (and nice gaussian ADC histograms). While scans are running, the
data will not be updated, so the data shown may be out-of-date.
At this point, the input levels are set, and we need to set the internal scaling of GUPPI via the
parameter. The example blocks below should have reasonable starting values for that parameter. To do this, run a
scan, and once data begins flowing (which you can tell via
) start up an
instance so that you can see the bandpass. Decide on how much you need to increase or decrease the scaling linearly, and change the
parameter appropriately. When the scan is over (or aborted), re-configure and re-run the
should now show "good" levels for the bandpass. Remember that we would like the average passband to be between 30-50 or so. Since these scans had incorrect scaling, they should not be used in your data processing, so make sure that if you are saving real cal scans, take a new one once
is properly set. The bandpass for saved cal (and fold-mode) files can be plotted using
psrplot -pb filename
: Once you have found good CM4 and CM8 attenuator values for a balanced system and an appropriate
setting, those should stay relatively constant from session to session. So it is a good idea to jot those values down (or save the
param in your scheduling blocks) to use the next time.
: Be careful when copying scheduling blocks! They might have bad values of
in them! Once you set
for your observing session, make sure that the other configurations either do not
have it set (which means that it will continue to use the currently set value) or else have it set to the new correct value!
Once you have the input levels of GUPPI set, you are ready to take real data. That is accomplished by configuring your scan and then running a
. The scan durations are set in seconds, and they determine how much data you will take. Note that for short scans, you should set the duration about 5 seconds longer than the amount of data that you really want. For example, if you want 6x10-sec dumps for a cal scan, set the
parameter to 65. An example of a scheduling block to track a well known MSP is:
# Slew, balance, then take data...
bright_MSPs = Catalog(pulsars_bright_MSPs_GBT)
# Track is how we take data now.
# Scan duration is in sec. Recommend you
# add 5-sec to account for some delays in the system
Track("B1937+21", endOffset=None, scanDuration=65)
Similarly, if you want to take driftscan data (or need to test GUPPI on a maintenance day when the telescope cannot point), we can tell the GBT to track the current settings of the azimuth and elevation encoders (i.e. telling the GBT not to move):
# Take Drift-scan data
loc = GetCurrentLocation("Encoder")
Track(loc, endOffset=None, scanDuration=20000)
You can interrupt a scan by using the Astrid
button if you need to stop a scan early.
Monitoring your Data Taking
You can watch the standard output of the GUPPI data acquisition server by tailing the log file which is written in
on beef. I highly recommend that you do this as it will show you if you drop a lot of packets if your data rate is too high and/or too many others are working on
. Which reminds me: Always nice your jobs on beef!
> tail -f /tmp/guppi_daq_server.log
Other Example Scheduling Blocks
There are several other example configurations which you can copy, load into Astrid, or simply browse in
. They are:
/users/sransom/astrid/GUPPI_astrid_example.py The well-documented S-band search-mode example from above
/users/sransom/astrid/GUPPI_astrid_820MHz_cal.py A 200-MHz BW 'cal' scan using the PF1 receiver at 820 MHz
/users/sransom/astrid/GUPPI_astrid_820MHz_fold.py A 200-MHz BW 'fold' scan of a bright MSP using the PF1 receiver at 820 MHz
/users/sransom/astrid/GUPPI_astrid_Xband_fastdump.py A special 256-channel fast-dump mode at X-band for Crab Giant Pulses
/users/sransom/astrid/GUPPI_astrid_350MHz_fastdump.py A way to dump at 81.92us for 100MHz-BW mode data for searching
Track() example from above
Track() for driftscans example from above
If You Have Problems
Do not hesitate to call Scott
if you have issues!
434-296-0320 or Cell:
Note: If other GUPPI-team members are willing to have their numbers on here, please edit!
- Do not run any commands from the GUPPI prompt!
- Do not run
guppi_set_params from the command line at all! This is all handled by configuring in Astrid now.
- Develop an less-kludgey way to balance the converter modules
- Implement the full GUPPI Balancing MR for fully-automatic balancing
- 21 Sept 2009