VEGAS To Do List

This page was forked from VegasOldToDoList on 23rd September 2015. Go to that page for historical information


VEGAS Spikes (Complete by mid-October)

  • Complete MR
  • Modify Manager as necessary
  • Implement GBTIDL routine
    • minor tweaks needed
  • Document
  • Characterize / Document non Fs/64 spikes
  • Finalize plans for RFI scans
  • Draft MR is located here
    • Richard will review and enter comments
    • Need software engineers to check. Review assigned partially to Bob Garwood (GBTIDL) and Joe/Ray (FITS)
  • [2015-10-19] Comments appear to have been added, but not yet approved - Richard will take over from Adam
  • [2015 -11-02] complete MR definition with Bob and check MR
    • plan to implement MR upon completion is a manageable effort
  • [2015 -11-09] MR development continues
  • [2015-11-23] needs checked and then test plan and sponsor check
  • [2015-12-07] no progress
  • [2015-12-21] no progress

Git repository

  • General cleanup - delete obsolete BOFs to make appropriate for DIBAS access/download (maybe via another repository)
  • Add all hardware information (mechanical drawings, schematics, BOM, etc)
    • separate Hardware and Software repository branches (in cooperation w/South African CASPER users)
    • simple plan to be drafted
      • Ray is looking at Git structure and branches in collaboration with CASPER with help from others and will make suggestions.
      • Ray, Jason, will lead effort in consultation with Jack Dave Randy Joe
      • Electronics knowledge transfer has not yet happened
        • Git training will be needed
      • Determine how to use Git and scope of Electronics use of the repository
        • Mark to start MR
      • Needs a brainstorming session to determine scope - maybe next time Dave is in Green Bank
        • Must consider interactions with CASPER, DIBAS, and VPM
  • [2015-12-07] no progress
  • [2015-12-21] no progress

Defer until April 2016


  • Need to review error messages, make sure distinction between warnings and errors is correct, etc.

Operational Issues (some may be solved as Ray 'does his thing' on other VEGAS parts)

These are all important issues. However some of these may have already been solved. We will perform analysis on the historical VEGAS messages of the system to determine which ones are still ongoing.

  • Arm time is in the past bug
  • VEGAS HPC program taking too long to be ready.
  • VEGAS aborted due to detection of invalid data.
    HPC code bug. This is a rarely occuring, not reliably reproducible bug. Solving it would require code analysis. The effort involved would be non-trivial, and potentially a time-sink. It is probably better to spend this effort finishing the Matrix-based HPC code. It would be fine for this to be tackled after the Matrix-HPC change. But it does need to be addressed. The fact that VEGAS definitely produces invalid data on occasion means that all data is potentially suspect. If we cannot "fix" the issue, we at least need to know what triggers it.
  • VEGAS hangs in aborting Need more information about how this happens
  • "IF_BITS" problem Has this been fixed with the new IF module?
  • Need to revisit integration / scan length algorithms
    • Don't want to produce little "runt" integrations
      We (Joe and Ray) don't really understand why this is an issue. Because Observers find it very confusing. The runt integrations are a artifact of the algorithm. The algorithm needs to be improved. If nothing else, the config tool / Manager / Mapping case / Tracking case are not all self-consistent. Any algorithm is going to have corner cases like this. VEGAS is going to be our primary backend for the next ~ ten years (maybe for ever). We should understand and deal with the corner cases.This is a completely deterministic problem. We're not sure that the decision to not create an integration belongs in the manager. Perhaps this is a post-processing problem? I agree that it may not be a manager issue, but I don't think it is a post-processing issue. It is a system issue, all the way from Astrid - in fact, from the mapping calculator - to the post-processing stage. It needs to be handled correctly and consistently the whole way. Observers do not know or care whether this is handled by config tool, Manager or whatever. It should just be correct.
  • Problems configuring for 0.5ms integrations in mode 1 Has this occured recently? Yes.
  • Ray would like to clean out old parameters at some point.
  • 6Q115 MR - remove "res" keyword (Awaiting implementation) Need to check if this has been done. MR not delivered.
  • Is final Valon synthesizer drive in both VEGAS and general CASPER repositories, and in use? In GB VEGAS repo. Will review status of C and Python code for this.

Documentation (Complete what Adam can)

  • review Proposers Guide (mainly cleanup of tables and minor text adjustments)
  • review Observers Guide
  • Merge LateX source for Proposers Guide and Observers Guide
  • Review LO switching memo.
  • Produce definitive VEGAS tables excel spreadsheet, and Excel -> LaTeX python scripts
  • Update Status Update page

Potential KFPA Observing Problems

  • Do not work on these unless they can be replicated
  • KFPA ghosting problem
  • KFPA subbeam nod problem
  • wideband KFPA channel problem

General Astronomical Commissioning (Requires GBT time)

  • Specifically check latest BOFs for modes 1-3.
  • Characterize final baseline stability
  • Characterize final time stability (Allen Variance)
  • Characterize linearity

Polarization Commissioning

  • Not part of VEGAS project
  • 3rd party work has progressed significantly since SDSS



BOF file rebuilds (Complete in December, 2015)

  • H1K and H16K (Modes 1,2,3) look good in the SRBS, but need to be astronomically validated.
  • L1/LBW1 (Modes 4,5,6) were reverted to an old build. We need to build and validate them under the correct CASPER release
    • no manager nor config tool changes remain - MR may need to be closed
  • No work in last week due to VPM builds and lack of test time
  • Marty to establish VEGAS Mode 4,5,6 v. VPM priority
    • Probably Randy can work both simultaneously as there is "down time" during BOF builts.
  • [2015-10-19] No update on progress available
  • One remaining build in the works (modes 4-6) to solve the issue of needing to use a previous version to get a successful build.
  • [2015-11-09] Joe to test current version provided by Randy. If these tests are successful and subsequent astronomical tests passed then this issue will close.
  • [2015-11-23] Joe's tests have been successful. Richard will attempt astronomical tests 24-Nov.
    • astronomical tests had issues with switching signal section. Randy and Ray are researching
  • [2015-12-07] A number of different iterations tested. Next version to be tested 8:00am Thursday 10th December.
  • [2015-12-18] Version 137 of VEGAS l1 (for modes 4, 5, & 6) was successfully tested by Richard, Ray, and Randy Thursday morning. At this point, it appears that version 137 will soon be designated as the released version for VEGAS modes 4, 5, & 6. This completes our efforts to unify all VEGAS spectral line bofs under our latest development platform and library.

Analog IF Module Completion

  • Need to finish four more banks. Should be complete in a couple of weeks.
    • A&B replacements will be installed Thursday and G&H removed
    • Next week G&H will be replaced
    • Execute astronomical validation tests and then the activity will be complete
    • The last two modules (G&H) will be installed om Wednesday afternoon 1-4p.
      • successful tests will complete and close this item
    • [2015-10-19] Complete and close

-- MartyBloss 2015-12-18 -- RichardPrestage - 2015-09-23
Topic revision: r98 - 2016-08-24, RichardPrestage
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