VEGAS Pulsar Project Meeting: 2016 February 29th 2:00 - 3:00pm ET

Room / Connection Details

• GB-137 / Soc 280
• 192.33.117.12##7144
• 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

Present

• Vereese, Randy, Ryan, Scott, Jason, Richard, Marty

Agenda

BOF file status updates

• Switching signal builds
  • Testing continues as new builds come in
  • 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
    • This is because packets are not flowing
      • Ryan to double check addresses
      • Can also try it in DIBAS
• c1500x4096 mode
  • Recompiled GPU transpose code
    • 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
    • No update
  • Is this the SS version?
    • This has been tested and performs identically to the previous build, i.e. scans run but with dropped packets.
• c1500x0512 mode
  • Astronomical verification
    • Used successfully during Breakthrough Listen tests (though with some packet loss in the RAW mode)
    • Ryan talked with Andrew Siemion about analysis of their pulsar data. This will be done in the near future.
• c0800x0512
  • Randy and Jason rebuilding for switching signal support
  • Ryan will test as soon as this is done and will then try for astronomical verification
• c1500x2048 mode
  • New build is ready for Randy and Jason to test
    • Ryan will test at end of day today
• 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
    • We think this already should be happening correctly
  • Duplicated signal in i0800x8192
• Low bandwidth modes
  • Need to decide on how to proceed with FFTs being done either on FPGA or by GPU. This is a hardware vs software approach.
  • If bandwidth is low enough all processing could be done on the GPU instead of the FPGA, but is there any advantage one way or the other?
    • More precision in the GPU
    • Could use one HPC to process full 200 MHz, otherwise need to do FFT on the FPGA
    • GPU code would have to do filterbank, not just coherent dedispersion
    • If done on the GPU, very minor changes to the BOF files, but need CUDA development (personnel is a problem)
    • If it is done on the FPGA, new BOFs have to be built, not clear how this would be done
    • In coherent dedispersion, time series would be fed into HPC, which would do a PFB/FFT, corner turn, FFT, complex multiply, FFT, accumulate
      • Need to add the PFB/FFT and corner turn, the rest is part of the coherent dedispersion algorithm
      • In incoherent mode, just do the PFB/FFT and then accumulate
      • Roach output would be the same as the spectral line modes, so we would have to merge the PFB/FFT, corner turn, and coherent dedispersion blocks, but these all exist
    • Another option is to use DSPSR, which can already do everything, but would use shared memory, which is going away
  • Some question about how to handle switching signal support
  • • Spectra lline BOFs have full switching signal support, but we don't need this for pulsar modes
    • Randy will need to look into how easy it is to back out the nchan dependent spectral tick in those modes and implement a fix multiple of spec tick

Software

• Configtool changes
  
  • Astrid still reports that VEGAS failed to balance when trying to adjust LBW gain. Still need to work on disabling this for pulsar modes. However, we can now set independent scale parameters for GUPPI and VEGAS.
  • Astrid still issues 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 parameters allow for this now that we can control the scale parameter separately?
  • Bandpass is flipped. This is expected because VEGAS has a different sense than GUPPI
    • Justin implemented a fix for this that queries the IF Manager for the sideband of the VEGAS IF module inputs and modifies OBSBW parameter appropriately
    • Waiting to verify fix
• Switching signal generation
  • Cal successfully controlled by VEGAS
  • Justin made a change to actual spwer calculation, now matches requested swper
    • Waiting for final verification
• Matrix HPC
  • Ray has been working on and seems to be happy with his work on the LBW modes

GBT testing

• TBD
• Our software changes seem to still be causing problems, particularly with cabling file since it is not under version control
  • We should do more testing in simulator
  • Ryan and Justin are going to merge VPM/release branches of vegas.conf so that we won't need to change anything in etc/config anymore at all. Is there any reason not to do this?

Wideband AP

• New circuit boards have arrived
• Nathan will start populating the boards when he has a chance but is currently working on servo replacements
• Randy hopes to start testing next week
• Vereese has selected a summer student to help on control development

VEGAS/DIBAS-style backend for FAST

• Work progressing as independent project
• Project has been descoped to provide a simple clone of DIBAS with no upgrades
  • Given the OK to proceed by Beasley

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

• TBD