EVLA SSR Meeting Date: 2002-09-11 Participants: Brisken, Brogan, Butler, Chandler, Clark, Frail, Myers, Napier, Perley, Rupen, Taylor Secretary: S. Myers ------------------------------------------------------------------------------ 1. The working versions of the documents for this meeting are contained in the archive http://www.aoc.nrao.edu/~smyers/evla/ssr/ In particular, the documents considered were EVLA Software Science Requirements: http://www.aoc.nrao.edu/~smyers/evla/ssr/evla_requirements_11sep02.pdf EVLA Offline Data Processing Requirements: http://www.aoc.nrao.edu/~smyers/evla/ssr/evla_offline_11sep02.pdf 2. Barry pointed out that we should be wary of writing requirements for features that were too complicated and would be too costly for the project. I think the consensus was that we should keep this in mind, particularly when setting the priorities, but that we might want to err on the side for asking for stuff we want regardless of its probable difficulty or price. There will have to be a costing and negotiation between EVLA and e2e in any event based upon our requirements. 3. Discussion took place of the split between e2e and EVLA responsibilities, particularly regarding the Real-Time parts and the Scheduler/Archive parts. It was decided that the Real-Time chapter (currently included at the end of the EVLA SSR doc as a placeholder) should be removed and might eventually become its own document. Items from this section relevant to other sections (e.g. scheduler, archive) should be copied into those sections. 4. The e2e project, in particular Boyd Waters, wanted to have some fiducial observing projects or modes delineated, similar to Use Cases (though not as rigidly formatted or prescriptive). We thought that a few of us could work with him on this (TBD). 5. It was suggested that there were special calibration needs, e.g. for calibration of stitched correlator subbands, or delay & rate calibration, that should be considered. It was thought that we probably did not need a special "EVLA Calibration Plan" document, but that these should be melded in with the requirements here (particularly Pipeline and Offline requirements). 6. It was clear that Operational Issues had impact on some of our requirements, and visa versa (e.g. Proposal Handling, Scheduling), and that fairly close contact should be kept with the Operations group (e.g. Peggy). We need to keep them in the loop and get feedback from them on plans and implications of our requirements. Along with operational input, we must also keep in mind the engineering staff, who will have their own special needs and concerns about interaction with the hardware. I presume Peter and Barry will keep them in the loop but we should keep a look out for items that need some consultation in this area. 7. Timeline - It was decided that the first of the two documents presented here, the Scientific Software Requirements on the first 5 of 6 e2e areas, would be the first target. The Offline Requirements could come slightly later. The timescale proposed was to have the SSR document completed by 1 November 2002, allowing it to go out to review and thus completed by the end of the year. This should give sufficient time for it to be translated (by Dale) into e2e targets for the next development cycle decision point (2003 Q2). Note that this timescale has slipped one month from the one proposed by Myers at the July PDR, mostly due to lateness in delivering the first drafts (my fault!). We should still be in good shape for getting this out and reviewed on a short enough timescale to impact the next e2e development cycle. Note that Myers will be away from 15 Sep to 11 Oct (though will be in email and/or phone contact), and Butler will be in charge during that time (Myers will pass off the current document drafts when he leaves). The eventual quantification of these requirements, in a future auditing or benchmarking or trial phase, was discussed. No final plans were made, and we have to see how this would interface with the e2e spiral development scheme. 8. User input - It was stressed by Rick Perley that we need to keep the channels for input from the user community open during this process. Due to the short timescale imposed on this requirements writing process, we obviously cannot canvas the general VLA user base, but we should make sure that representatives from the EVLA External Advisory Committee, and perhaps the NRAO Users Committee, in the loop so they can comment, and perhaps include them as official reviewers. In the meantime we will have to keep in mind that we also represent the users when writing these documents. It was pointed out we should advertise this process on the web, and in the appropriate newsletters and email lists. Bryan is in the process of setting up an email exploder for evlassr. 9. Priority Scheme - it was thought that the timescale-only scheme used in the ALMA SSR (SW-11) and the priority-only scheme used in the ALMA Offline (SW-18) requirements should be combined into a 2-axis system to be used in both docs. This is: Priority: 1 = critical (must be present and work well) 2 = important (~90% should be there, should work well but some latitude on execution) 3 = desirable (useful upgrades, perks, or future improvements) Timescale: A = transition phase (2004 Q2) B = prototype correlator (2005 Q4) C = shared-risk science operations (2007 Q2) D = full science operations, completion of EVLA Phase I (2010 Q2) E = "eventually" sometime after completion (ongoing) Note - the dates are from my reading of the EVLA Project book. It was discussed whether we want to have a binary priority scheme (required, desirable) or more subdivisions. We will see how the current scheme goes. 10. Volunteers were asked for to concentrate on specific sections of the requirements. The list is: Section Team Contact ----------------------- ----------------------- ------------ [SSR doc] Proposal Preparation Butler, Clark Ye Observation Preparation Chandler, Rupen, Taylor Waters? Scheduling Clark, Chandler, Myers Waters Archiving Butler, Clark Benson Pipeline Rupen, Brogan, Brisken Kemball [Offline Doc] Offline Processing Myers, Brogan, Brisken Kemball I will probably be doing some editing on the documents through the end of this week (old versions will be archived on my site in the directory http://www.aoc.nrao.edu/~smyers/evla/ssr/ in case I make some later changes you don't like, or you need to diff versions). The way to proceed is to take the version I produce at the end of the week, and edit on these sections. Bryan (or I) will collate these into drafts as they appear. Please do not restrict yourselves to the assigned sections, please send suggestions or comments on all aspects! In particular, both Butler and Myers will check through and edit all sections. You can email the greater email list the various drafts to elicit comments, I guess Bryan can see how it goes and adjust accordingly the updating of the main draft. 11. Some action items, open questions, and food for thought: o Who wants to work on use cases with Boyd Waters? We probably need to start with a couple of standard modes, plus some harder problems that are likely to push the system. o How do we want to deal with operational issues? A separate document (e.g. "ALMA Operational Model, The SSR Point of View" http://www.aoc.nrao.edu/~smyers/alma/OperationalIssues.ps ) or part of this document, or at all (except what is implied by our requirements)? o Is a 3-level priority scheme what we want? Are the timescale milestones the correct ones? o What is the trade off between stuff we like and what we think is reasonable to get, and where is that decided? What things will require significant research projects (e.g. new algorithms for high-dynamic range imaging, RFI, etc.) and who will do this? o Who from outside (or inside NRAO for that matter) should we get to comment and/or review these docs? o What is the relation of this to the e2e Project Book? My view is that the e2e project book is e2e's view and is thus broader than our EVLA-centric requirements. We should probably fold in the e2e Project book where it makes sense however, we don't need to reinvent the wheel. o How does VLBA (and VLBI) fold into our requirements? o This is nominally for Phase I only. Do we put placeholders here for Phase II (a separate section? a later document?) o Anything missing? ------------------------------------------------------------------------------