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
Balancing
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
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