> > > 1 - WHAT KINDS OF DATA AND WHAT DATA VOLUMES ARE PRODUCED? > ---------------------------------------------------------- > For each type of data, please note its format, if it is produced/collected > by small standalone systems ... > > > 1.1 - ONE-TIME DATA > ------------------- > This would be for example data collected during contruction of a detector. > > - Detector component characterizations, identification, history ... We are collecting about 10 Kbytes of data per 256-channel chip. If we have a few hundred chips passing through our lab, this would add up to 2Mbytes of data. > - Detector mechanical data. Geometry, surveys, wire tensions ... > - other? > > 1.2 - RUN-TIME DATA > -------------------- > These would be data that are produced on a regular basis once we are running. > > - Data returned from slow controls: temperatures, voltages ... We have temperature, pressure, flow, voltage measurements coming back from slow control, totaling a few dozen channels. It is hard to estimate how much of this we would want to save. On day 1, you'd perhaps like to save them every minute, just in case there is something to trace back. After shakedown, much of this can be discarded again, and 1 save/hour may be sufficient. An even lower rate could be achieved by only writing parameters when they go out of range, which should be practically never. Even saving 50 words every minute adds up to only a few dozen Mbytes/year. > - Data produced by calibration programs: Calibration of discriminator thresholds: scan in the vicinity of the thresholds by varying the injected charge. 20 charge levels, each strobed 300 times to get about 5% statistical accuracy gives 6K calibration events. The results would be reduced to 1 value +- 1 sigma per channel. - Calibration of preamp linearity and gain: 20 charge levels, each 300 times, gives 6K events. If the preamps are linear, this would reduce to 2 values per channel; if non-linearities need to be parameterized, perhaps 2-4 values per channel. - ADC pedestal and pedestal widths: same as above, reduce to 1 value +- 1 sigma per channel. Database storage requirements are thus: for 6-8 words per channel, times 2*10**4 channels gives maximally 1.6*10*5 words of calibration per week. > - Component swap/repair/replacement histories This is probably a text file of sorts, kept with the documentation > - other? > > 1.3 - DOCUMENTATION > ------------------- > - Writeups, technical drawings, minutes, photos ... We currently have most of our documents on the web. Expectations are that there are one or a few dozen notes per year. We keep photo album on the web, expected a few dozen pictures per year Engineering drawings are in Unigraphics. These are files which are meaningless without the application installed, or without a translator to another expensive CAD/CAM application. I suggest these drawings be disregarded in the data base requirements process. > 2 - ACCESS > ---------- > This is more difficult to define, but also more important in that the >requirements and wishes expressed here will drive decisions on what the actual >implementations will be. Imagine an ideal situation, where we could dream up >the nicest software tools and interfaces. If we get lucky, those things may >already be out there... > > 2.1 - INPUT > ----------- > How are the data generated, and how would you like to see - from a users >point of view - the data transported to the 'central' data base. > > - are they/will they be in some existing data base program? If so, which? > - if they are/will be in some other computer form, what is it? Machine type, > software application, format .... > - do you want your program/application to write directly into the data bases? > - other? We are generating quality control data on silicon detectors. For now they are (asci?) files on a Mac generated by Labview. *** how much? *** We have some data in a Foxpro data base *** do we need to keep this? *** > 2.1 - OUTPUT > ------------ > How would you like to access this information. In the ideal world, what >would the user interfaces look and feel like? Some of you might have good/bad >experiences from previous experiments - lets hear them. > > - organization, searchability ... Calibration-like records: there should be a user interface which lets you search for, sort, list, extract calibrations from the data bases, with some manipulation and display capabilities too. The interface should be able to run on what Phenix decides is the lowest-common-denominator hardware (vt100? x-terminal?...) > - direct access from analysis programs yes for calibrations, and geometry data The web seems like a good place for this, with the following additions: * I would like to search through all PHENIX documents (even though they may be scattered over many machines). This should be a search over Phenix pages only, not the whole web. * I'd like to search by author, title, keyword, content ... > > - for documents: searching by title/keywords/content/date/author .... > - are all documents accessible from the web? All except CAD/CAM files. > - other?