VEGAS Pulsar Project Meeting: 2016 February 1st 2:00 - 3:00pm ET

Room / Connection Details

  • GB-137 / Soc 280
  • 434-817-6443

Housekeeping Details

  • Main wiki page
  • gbsapp Mailing List
  • Location and regular date and time of meeting - agreed weekly on Mondays; GB-137 / Soc-280; 2-3pm ET
  • ETK codes:
    • Electronics: 432510.GB3015
    • Software: 893252.GB3015
    • Science: 432540.GB3015

Resource Allocations

LYNCH, Ryan 0.15


  • Richard, Ryan, Scott, Marty, Justin, Paul


BOF file status updates

  • Switching signal builds
    • c1500x4096, i1500x2048, and i0800x2048 all seem to behave in the same manner as the non-SS builds
    • c0800x4096 mode scans fail to initialize
      • NETSTAT appears to remain in "Waiting" for too long, and Manager aborts because the hpc process is taking too long to start,
  • c1500x4096 mode
    • Recompiled GPU transpose code
      • DONE Complete
    • nVidia profiling
      • BLI found using packet-sockets solves this problem and found them highly efficient. That code is done and available.
        • Will need to integrate this into current code, but other modes have higher priority
        • Ryan to contact Dave McMahon about these changes to see what needs to be done to incorporate them into our "release" (or pre-release versions)
    • guppi_daq_server version comparisons
      • Ryan to test at some point
    • Is this the SS version?
      • Previously no, but Ryan has starting testing this
  • c1500x0512 mode
    • Build status
      • Built successfully
    • Scans failing during long integrations
      • Update status shared memory code to use different data type to accurately capture packet ID
        • Version built for Cuda 35, but need Cuda 75 for use on srbs (can't run these long scans using VEGAS hardware)
    • Astronomical verification
      • Used successfully during Breakthrough Listen tests (though with some packet loss in the RAW mode)
        • This loss was in the net thread
  • c1500x2048 mode
    • Randy built a version with SS support
      • Ryan tested but there problems with bandpass
      • Low channels appeared to completely saturate, despite raw counts being within an acceptable dynamic range
      • Higher channels seemed OK
      • Randy and Jason are looking into the problem with this build
  • Fix for nchan calculation in coherent modes
    • verified - ready to roll into other modes
  • Bandpass issues in i0800x0064, 0128, 8192
    • Spent some time testing 64 channel mode
    • Injected a digital tone at 100 MHz, which always shows up at the correct frequency
    • Tone shows up in the correct bins, but generates spurs if injected at Fs/8 or nearby
      • Spurs move with the test tone and decrease with amplitude if you move away from Fs/8
      • May be problem with MMCM or OGP calibration
    • A suggestion was made to build a BOF with digital noise source to test
      • tough for 8192, others should be ok
        • test w/ 64 chl mode since testing already done by Jason
      • work needs to prioritized against other work
    • Jason worked with VEGAS hardware and saw same issues as on srbs
      • On srbs, spurrs were showing up when injecting a tone at Fs/4
    • DIBAS modes have clean bandpass
      • On VEGAS with AP, spectrum still looked poor, with spurs showing up
    • Result of discussions with Paul regarding OGP/MMCM calibration
    • Duplicated signal in i0800x8192
  • Low bandwidth modes
    • New filter coefficients
    • Spectrum output instead of time series
    • Implement PFB code
    • Could single GPU keep up with coherent dedispersion?
    • Reviewed John's email suggestion with Paul - more detailed query with John recommended
      • Is there an advantage to FFTs in FPGA? (none identified)
      • GPU (S/W) vs. FPGA (H/W)
        • GPU likely preferable if it can handle it
          • requires a benchmarking test
          • existing FPGA filter work could be affected
        • S/W CUDA-savvy resource constrained
          • Justin will look at it
      • How about running a higher bandwidth modes and ignoring some of the spectra?
        • limits on number of channels likely an issue
      • Ryan to email John to discuss some of this


  • Configtool changes
    • Ryan and Justin tested maintenace time
      • Overall everything went well. Both backends configured properly and successfully took data on the S-Band noise diode
      • Some remaining issues
        • VEGAS bandpass does not reflect the S-Band receiver response the way GUPPI does
          • GUPPI i0800x2048 S-Band.png
          • VPM i0800x2048 S-Band.png
          • Ryan, Randy, and Jason to test using noise source to try and isolate the problem (Tuesday at 1:00 pm)
            • TODO: What does it look like with just VEGAS?
          • All scans were with i0800x2048 mode
        • Astrid reports that VEGAS fails to balance, although levels in the VEGAS power monitor seem normal
          • This is probably because Astrid cannot balance the requantization gain
          • This the equivalent of the guppi.scale / vegas.scale parameter. Can we balance this automatically in pulsar modes?
            • LBW gain so that dBFS is equivalent in and out of FPGA
            • There is an MR that describes balancing for spectral line modes
            • In spectral line mode this is handled during Balance
            • Are spectral line snap blocks in pulsar BOF files?
        • Astrid issued a warning about a discrepancy in the requested and actual IF rack power levels, though this did not cause a failure
    • An observer already expressed interest in configuring GUPPI and VPM in slightly different modes. We were not planning to support this but if we did, how much effort would it be?
      • Justin thinks this would be fairly easy
      • If we allow different scale parameters then we will have to support something like this anyway
      • Backend-specific parameters would probably be easy to set independently but higher level parameters like integration time would be harder to set independently
  • GBT Status shared memory parameters in PSRFITS headers
    • Done
  • Switching signal generation
    • Cal successfully controlled by VEGAS
    • Actual swper still not matching requested swper
      • Still outstanding
      • Justin to work on it some more this week
      • Incidentally, in dual backend mode DCR was automatically chosen as switching signal master
  • Matrix HPC
    • Justin has all threads running for all observing modes, and FITS files are being written
      • Need to check that FITS files are being written properly; Ryan to help with this
      • Richard suggests automating this by comparing FITS files with standards that are known to be correct
    • Justin working on VEGAS Manager to use Matrix instead of older guppi_daq
      • Justin hopes to have this done within 1--2 weeks.

GBT testing

  • Looking into VEGAS vs GUPPI bandpass differences

Wideband AP

  • Status of new filters
    • Should be here in about 1 week

VEGAS/DIBAS-style backend for FAST

  • Work progressing as independent project
  • Any overlapping work to note at this time?

Multicasting for spectral line and pulsar modes

  • Modifications to ROACH configuration and net task must bind to a multicast group instead of a specific host
    • All the 10-gig addresses on the ROACH would be multicast groups, and config will be told which to bind to
    • Some changes to net task code (in VEGAS HPC and guppi_daq code) to initialize sockets

Date / Time of Next Meeting

  • February 8

-- RyanLynch - 2016-02-01

Topic attachments
I Attachment Action SizeSorted ascending Date Who Comment
GUPPI_i0800x2048_S-Band.pngpng GUPPI_i0800x2048_S-Band.png manage 6 K 2016-02-01 - 10:20 RyanLynch GUPPI test scan using S-Band receiver in dual backend operation
VPM_i0800x2048_S-Band.pngpng VPM_i0800x2048_S-Band.png manage 7 K 2016-02-01 - 10:19 RyanLynch VEGAS Pulsar Mode test scan using S-Band receiver in dual backend operation
This topic: CICADA > VegasPulsarModes > VegasPulsarProjectMeetings > VegasPulsarProjectMeeting2016Feb01
Topic revision: 2016-02-01, RyanLynch
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback