Paul will circulate this to select members of the scientific community for confirmation
Re config_tool; we agreed that have the IF routing performed for both backends was extremely important, but having the config_tool be able to initiate scans in both was not (one can be done with procedures).
This has previously been possible for GUPPI / GASP
Paul noted that work has already been done based on the GUPPI_DAQ_SERVER, and we should check what others have done before commencing our own work.
We agreed a software / hardware test setup independent of the VEGAS observing hardware would be essential to make good progress on the project.
We do not have a spreadsheet for short-term commissioning effort, or science group commissioning time. This should be created
The long-term commissioning can probably be performed with Nanograv observing time.
Notes from meeting
We agreed no need to implement "C" modes until someone makes a compelling request to use them.
ultra-wideband modes not needed until wideband receiver is built; this is at least a few years away.
config_tool can support configuring IF system for VEGAS / GUPPI as long as the advanced configuration (restfreq dictionary) is not needed.
Action: Richard to confirm this is the case.
Joe has already checked other work which has been done on GUPPI_DAQ_SERVER
For the hardware simulator, we propose
Use the SRBS Roach II
Manager can be called VEGAS, since it is in a different installation
Need a spare VEGAS Analog IF module; Richard to check with Galen
Need a spare GPU machine; John proposes the VEGAS hot spare
wideband artificial pulsar needed; this should come from WVU project by end of summer
Action: Richard to set up a wiki page to gather information together
Outcome of Electronics Group Planning Discussions
Options for low-bandwidth modes were discussed. We think it is not feasible to use low-frequency sampling to take care of this, and we will need to do downconversion/decimation to achieve the low bandwidths. There are a few possible paths:
Use the asynchronous PFB/FFT recently developed to clock in valid lower-rate filtered data to the pfb-fft.
Use a PFB to filter out the desired bandwidth and pass it on to the GPU for further processing.
Jason has developed a spreadsheet showing the development path to be taken. We will go over it in the meeting.
Notes from meeting
Approach bullet one above is preferred, and has the benefit that it leaves the HPC software untouched.
Do we need smaller than 32 channel modes? No, apart from a special case:
It would be nice to channelize the data such that one channel goes to each of the HPC nodes (with VEGAS and GUPPI HPCs, could do 16 channels).
Outcome of Software Group Planning Discussions
Ray is developing the plan for a shared software framework (shared with SRP project). Initial version of plan should be ready by the end of this week.
We can use the DIBAS software for initial testing.
Progress on shared project plan
Individual components still in development.
Any Other Business
Science group ETK code didn't work. Anyone else have problems?
Electronics works for me (JMF)
Paul - we need to capture the requirement for 2 or 4 bit data storage in the output PSRFTS file.