DEIMOS Software PDR Planning Meeting Wednesday, April 26, 1995 NS-143 9:30 am Present: Sandy Faber, Bob Kibrick, Steve Allen, Dean Tucker, Lee Rottler, David Cowley, Deanne Lago. This meeting is to determine if we are on track for a PDR to be held in July. We also want to determine the level of detail and what topics of software should be covered. Bob was hoping to have ready before the PDR an overview of the global data flows through the system and identifi- cation of various types of files that come in/come out and how they are interrelated. We would like to get the participation of folks involved that understand the problems you get into when designing a multi slit instrument. We have a lot of information to cover is it feasible to break this up into more than one session with different review boards? One of the results of the PDR would be a verification that we have a clear understanding of what the requirements are and then ask for feedback from peers to deter- mine if our view is valid. At the CDR then we present how we are actually going to solve the problems. It should also be determined what set of data reduction software is perceived as part of the deliv- erable instrument and what is considered "add-on's". Possible Topics To Be Covered: Detector Readout, Data Flow: (Block 1) · Data Bandwidth · Bus System · Fits-headers · Image Data Flow · Data Access/Storage · Disk/Image Formats (Geography) · Performance Specifications · Archiving CCD software is driven by the detector characteristics which will not be finalized in time for the July PDR date. We may have new Leach S-bus test results by the end of August. By postponing the PDR until after this information is obtained we may be able to discuss this topic, we need to determine when we will nail down a requirement on what the level of bandwidth is we are trying to support back to the controller. We also have to determine what our per pixel time is. This will be hard to determine until we have the whole controller and also what chip we end up with. At some point we will need to make a "best guess" as to what we think the chip and electronics can deliver. Perhaps it will be feasible to do a cost bandwidth trade-off study soon. This by itself together with whatever the current state of CCD performance is at the time (best guess projec- tions) is all that we can contemplate putting into any kind of PDR before the end of the year. This is probably enough. We can't set final values until we actually have our chip in hand. Our PDR goal should be: 1) Completion of the cost bandwidth trade-off study; 2) Appraised and up to date chip performance from our possible suppliers; 3) Most probable plan and it's backup, but not "written in stone". We must determine: 1) what types of readouts do we want to be able to accomplish and their vari- ous combinations (packaging on the disk, overscan pixels, filling mosaic gaps etc.); 2) Time requirements (how long each operation should take in real time); 3) Disk formats; 4) Estimate of storage requirements; 5) Other peripherals except display (how it is backed up to tape and interac- tion with Keck archiving system); 6) Keywords (fits header), Hilton has asked for a preliminary list of all keywords at the PDR (detector keywords, moveable mechanism keywords etc.); 7) ATM (Asynchronous Transfer Mode) is a high speed network technology which will most likely tie together whatever set of computers we have for DEIMOS, and possibly our disk sub-system. It is basically a scalable high speed communications method. If we decided to have a PDR in July, we wouldn't have our Leach S-bus tests in hand, this item only impacts a small piece of our goals, however we need to know how clear a picture we want to have on the underlying hardware that the software runs on at this review. Image Display, Global Data Flows, Image Formats: (Block 2) This area probably can't be covered the same day as Detectors/CCDs and it is probably a different audience. · Guider · Alignment Acquisition · Instrument Set-up (i.e. focusing, instrument tests etc.) · Instrument User Interface We need to determine how this type of information will go to disk, what sort of fits files and key- words are needed. A schematic hardware plan and budget will also be needed along with the detailed list of requirements. Basic requirements should be prepared for each area listed above and then our plan on how we intend to address those requirements. Image display prototypes would be appropriate, sort of a walk through of an observing session by showing an actual rough form simulation of acquiring an object and doing an alignment. This will give us a verification that the steps we are taking for this process are complete. What kind of graphical overlays do we need to tell us which spectrum we have, what object it is, do we want to be able to obtain a quick look? We need to determine what lists of operations we want to be able to do? These operations are the same no matter how many monitors we have con- nected, so the monitor issue is not pressing at this time. Motor/Instrument Control: (Block 2) This is a straightforward item, we know pretty much what we are going to do and probably should go and do it. The new things for this instrument are small compared to the big picture. The com- mand set is roughly the same as others, etc. A statement of requirements should be made as we need this to begin our work and a plan should be presented. Most of the controls will be an extension of MOS and HIRES that we are already familiar with. The rotator interaction with the telescope should also be addressed. We need verification on whether or not our requirements document is adequate as far as a time (i.e. time going between gratings, how long it will take a grating to find its position, etc.). Science Issues/Astronomer Interface (Acquisition, Alignment, Data Reduction): This area is a low priority at this point because it is coming together rather well in connection with LRIS. Drew Phillips expertise will be invaluable here. What the astronomer OA interface will look like, who will control what, how big will it be, what can you do with it. Possible Committee Members: Detectors: John Cromer Bob Leach ? John Kerr Hilton Lewis Al Conrad Chris Clark Pat Waddell Detectors will require the most time during the PDR and this is most likely a separate meeting. Image Display / Motor & Instrument Control: The Science Advisory Team: Mark Davis David Koo Chuck Steidel David Tytler Roger Blandford Project Personnel: Tom Bida Al Conrad William Lupton Hilton Lewis Barbara Shaffer (?) NASA Representative (?) In House Task Groups: Detector Readout / Data Flow: Steve Allen - task leader, Sandy Faber, David Koo, Drew Phillips Image Display / Data Reduction: David Koo - task leader, Sandy Faber, Drew Phillips, Bob Kibrick - (outline) Object Acquisition / TV Guider Interface / Slit Mask Alignment: Sandy Faber, Drew Phillips Instrument Utility (Set-up) Routines / Focusing: Sandy Faber, Bob Kibrick Instrument User Interface: Dean Tucker - task leader, Sandy Faber, Engineering Personnel If requirements could be created/developed within 6 weeks then we need to develop our plan on how we plan to obtain the requirements which could take 6 weeks.