> 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 ... > - Detector mechanical data. Geometry, surveys, wire tensions ... > - other? PMT's ===== 1) Spec of the PMT (manufacturer part #, # of stages, maximum HV rating, typical gain, transit time spread) 2) physical size of the PMT 3) 1920 PMT's will be used for TOF. For each PMT's we need to record A) data sheets (especially blue sensitivity from Hamamatsu) B) initial gain factor measured on the bench 4) We will also has a table of (location <--> serial #), where location is the location of the tube in PHENIX detector. 5) Signal cable length from each PMT's(1920) Scintillators ============= 1) spec of BC404 (rise time, fall time, amount of light with MIP etc...) 2) physical size of two types of scintillator(short and long) 3) physical size of light guides 4) typical attenuation length Electronics =========== 1) sepc of FEE 2) spec of HV supply 3) spec of DCM 4) ch vs. time constant + offset calibration constants for each FEE ch. 5) location (PMT's)<--> module id table should be stored 6) Physical location of the FEE crates 7) signal propagation velocity temperature dependence Geometry ======== 1) physical size of a panel 2) location of each slats on a panel 3) average material thickness in radiation length 4) surveyed position of each panels comments ======== Any major modifications of the system with dates > 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 ... > - Data produced by calibration programs > - Component swap/repair/replacement histories > - other? Slow controls ============= 1) temperature and voltages every 2-4 hours (may be related to t0 drift) 2) low voltage and current + fluctuation width every 2-4 hours to record the fluctuation, voltage and current have to be monitored continuously but written to database once in 2-4 hours. 3) sometime, ARCNET chips need initialization. It would be useful if it is monitored and status is store in the database at the frequency of system initialization. 4) system clock frequency in front of the FEE crate Calibration program output ========================== 1) time serolution of reach slats(960) from Laser calibration once per day 2) relative timing difference slat by slat(960) every 2-4 hours 3) t0 after slewing correction(960) every 2-4 hours 4) PMT gains (1920) every week 5) slewing parameters per PMT's(1920) every 1 - 2 weeks 6) light propagation time through scintillator + position offset per slat(960) every 2-4 weeks. Component histories etc... ========================== 1) dead/bad channel status by PMT, laser calibration fiber, HV module, FEE module, FEE crate, DCM 2) FEE and HV module replacement history 3) ARCNET initialization packet send and read back (~200 word * 120 FEE module) > 1.3 - DOCUMENTATION > ------------------- > - Writeups, technical drawings, minutes, photos ... > - other? We are working on writing up all documents. We do not know what is the best way to post it. On the WEB? > 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... 1) Most important thing is that we can get information very quickly(less than 1 s/calibration parameter set) 2) It would be nice to have dead channels appear in the event display with distinguishable color. I mean those information should be automatically available from event display. 3) fancy browser in which you can define columns and scope with searchability > > 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? In AGS-E802, we were managing only one official database file and that was the only place we could try out databse programs. It turned out people try to input values into it on try and error bases. Which caused lots of garbage accumulated in the official data base and slowed down the access unnecessarily. It would be nice to have a database test area where people try to input their data to database to debug their database retrieval programs and their database values. Or it might be advantageous to have one person take care of the database retrieval programs and tailer them to each subsystem. Main database should be protected from unnecessary garbage which tends to accumulate if there's no flow control. > 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 ... > - graphing, manipulation, display ... > - direct access from analysis programs > - for documents: searching by title/keywords/content/date/author .... > - are all documents accessible from the web? > - other? > It would be nice to have a program which shows the difference of the calibration parameters set by set graphically so that we can spot unusual behavior of the parameters. Mostlikely it is caused by fit failure. *********************************************************** *Kazuyoshi Kurita (U.Tsukuba) kurita@sgs0.hirg.bnl.gov * *Bldg. 510D Physics, Brookhaven Lab. Upton NY 11973 U.S.A.* *516-344-7374(o) 516-344-7841(fax) * *********************************************************** ------- End of Forwarded Message