Vegas Pulsar Commissioning Tests

Notes on how to test pulsar observing modes for the VEGAS backend system.

Recent Changes

• Added basic instructions for running the dealer/player software (-RL, 2/23/15)
• Created sub-pages for detailed notes for tests of each mode (-RL, 2/17/15)
• Created Google spreadsheet for summarizing testing progress for each mode (-RL, 2/17/15)
• Expanded on specific tests to run on the test pulsar to check for properly recovered pulse and timing (-RL, 2/13/15)

Mode Tests Summary

• VEGASHardwareTests
• Google spreadsheet summarizing testing status of all modes (editable by anyone)
• Detailed testing notes
  • High priority modes
  • Medium priority modes
  • Low priority modes

Initial Setup and Configuration

Descibe here how to configure your account / session in order to run the tests. e.g.

• source /home/gbt/gbt.bash
• source /home/gbt/sparrow/sparrow.bash
• source /home/pulsar64/guppi/guppi.bash
• Astrid session to use... (TODO)
• Where the data will go... (TBD)

Running the Dealer and Player

1. Start the player on srbs-hpc1
   1. ssh into srbs-hpc1 as monctrl (may need someone else to do this for you -- this will be annoying for testing, we should fix this (PBD) )
   2. source /home/dibas/dibas.bash
   3. Run 'player'
2. As yourself and from any computer on network, source /home/dibas/dibas.bash and run 'dibas_status'. This will let you check that things are being configured properly
3. Launch and interact with the dealer
   1. As yourself, ans from any computer on network, source /home/dibas/dibas.bash
      1. if python2.7 directories under /opt/local already exist in your PYTHONPATH this seems to break things. A workaround is to 'unset PYTHONPATH' before sourcing dibas.bash (PBD 2015/02/27)
   2. Run 'dealer' to bring up an ipython session with the dealer and player tools pre-loaded
   3. Connect to the dealer using 'd = Dealer()'
   4. Connect to the player using 'p = d.players['BANKA'] (note that different banks can be specified here)
   5. Set the desired mode using 'p.set_mode(<MODENAME>); for a list of available modes type 'd.list_modes()' or check /home/dibas/etc/config/dibas.conf
   6. Set other parameters; for a list type 'p.help_params()'
   7. To start, type 'p.prepare()' followed by 'p.start()'
4. Check dibas_status to find which directory your data is being written to.

Hardware testing

RichardPrestage comments: for each of these sections it would be nice to have subsections:

• how precisely to invoke the test
• what to look for during the test
• how to run any necessary data analysis software
• expected results, or how to compare to a "standard" data set.
• other useful notes

Tests of the data coming from the FPGA systems that do not depend on the "real" software.

• Use udp_recvor similar low-level software to inspect data packets directly:
  • Check basic packet format (number of bytes, counter values, etc) look as expected.
  • Check that packet counter increments as expected, and resets on arm.
  • Check that data packets are being received at the correct rate at all expected destinations.
• Use FPGA data-capture blocks(?)
  • Check ADC histograms
  • Check spectrum for expected shape (no spurs, tone shows up in correct channel, etc).
• For coherent modes, can use guppi2_stream library to generate/inspect spectrum.

Software testing

Tests of the software components that do not depend on having the "real" hardware.

• Can use udp_send or similar to generate data packets for testing.
• Check that everything runs as expected (ie, no errors/segfaults/etc).
• Check that software components create readable output files
  • Verify with standard data-processing packages (PSRCHIVE, presto, fold_psrfits)
• Check that software can keep up with expected data rates.

Integrating SW and HW

• Test M&C framework for loading FPGA designs
• Test code for loading parameters, read back correct values.

Testing with locally generated signals

Tests of the full system using lab-generated input signals.

• Sine-wave input
  • Input sine wave(s), check that they appear at the correct freq in output files
• Artificial pulsar
  • Uses python scripts in /users/pdemores/dibas/test_scriptsto test various modes
    • NOTE: These scripts may need to be edited for VEGAS
    • Check scripts for hard-coded parameters (e.g. observer, project ID) before running
    • test_codd.py tests a single coherent dedispersion mode
    • test_codd_multi.py tests a single mode and multiple VEGAS Banks
    • testy.py tests a single incoherent dedispersion mode
    • codd_loop.py tests coherent dedispersion modes
    • inco_loop.py tests incoherent modes
    • loopy.py tests multiple scans of a single mode
  • Check that correct pulse period is recovered
    • If the data are on search mode, they will need to be folded first. PRESTO or PSRCHIVE can be used for this:
      • If using PRESTO, run a command like prepfold -p <period> -nosearch -npart 60 <filenames>
      • If using PSRCHIVE, run a command like fold_psrfits -t 10 -F <freq> <filenames>
    • Visually inspect the folded profiles
      • If using PRESTO, open the output poscript file (*.pfd.ps)
      • If using PSRCHIVE, use pav
        • pav -DFT displays integrated pulse profile
        • pav -YFpd displays phase vs time
        • pav -GTpd displays phase vs frequency
      • Does the pulse appear stable in phase?
      • Are there any dropouts or gaps in the data?
    • Calculate TOAs
      • Will need to make a standard template
      • If using PRESTO run a command like get_TOAs.py -g <template> -n 6 <pfdfile> where <pfdfile> is the PRESTO *.pfd output
      • If using PSRCHIVE run a command like pat -F -f princeton -s <template> <filenames> where <filenames> are the folded fits files
    • Use Tempo to recover the pulse period
      • Make a dummy parfile with the expected period
      • Make a tim file using the TOAs (Should the site code be set to @ (i.e., barycenter) for the test pulsar?
      • Run tempo -f <parfile> <timfile>. The fitted period should be correct and the residuals should be flat.
  • Run long (multiple-hour) test, check for time jumps
    • Follow the same procedure as above and check the Tempo output for any jumps
  • Run multiple-restart test, check for consistent pulse phase
• Polarization response (needs correlated signal; AP can be used for this)
  • Check cross-term phase stability during long test
  • Check cross-term phase stability on multiple restarts

Testing with astronomical signals

Tests of the full system using real telescope signals.

• Observe a test pulsar (preferably an MSP; B1937+21 is ideal).
  • Make sure pulsar is detected in all modes
  • Make sure timing aligns correctly between different modes, restarts, etc
• Long (multi-hour) test in certain modes?

Other notes

• Given the large number of different modes (# channels, etc), may not be practical to run all possible tests in all possible modes.
  • Make a 'basic' test plan for all modes, run detailed tests in several select modes?
• Same tests apply for both GPU modes and non-GPU pulsar modes.
• udp_recv and udp_send are available at http://github.com/demorest/net_test
• PSRCHIVE is at http://psrchive.sourceforge.net/
• Presto is at http://github.com/scottransom/presto
• psrfits_utils are at http://github.com/demorest/psrfits_utils
• tempo is at http://tempo.sourceforge.net/
• Note, all of this software is already installed at GB in /home/pulsar64.

-- RyanLynch - 2015-01-29