Hi Hubert, This is the best I could do for now. I am planning to contact PC and DC subsystem manager to discuss this numbers with them. I have done the estimates in great details for TEC and then scaled them for DC and PC according to number of channels. I will be out of town next week, so I will not be able to attend next videoconference. I will see you at BNL. > 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? In Central Tracking we have: 1) 48 TEC chambers 2) 40 DC keystones 3) 32 PC chambers The kind of data we will have are A) Wire Tension measurements B) Wire Position measurements C) Wire Gain measurements D) Electronics Gain Measurements E) Electronics Noise Measurements F) Electronics Pedestal Measurements This information will amount to about 30 Mb of data. > 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? We plan to monitor probably once per hour but we haven't yet studied, it is possible some quantity need to be updated more frequently (every 10-15 minutes) and others only once per 8 hour: - temperature, pressure, gas flow - HV, LV, Serial information downloaded into preamp or thresholds etc. - maybe alignement Also we will have to have a time history of the correspondance wire number- preamp channel #- FEM # - DCM # -power supply #-high voltage supply#-timing module #. We will also store the calibration data in the database and they will be the largest amount of data in the database. Assuming we need a calibration file every 30 minutes (TEC performance for example depends on accurate gain equalization) we might have to store 30 Gbytes of data in the database per year. > 1.3 - DOCUMENTATION > ------------------- > - Writeups, technical drawings, minutes, photos ... > - other? I think we would like to keep most of the documents on the WWW, but it would be nice to have a database able to do a search using our defined keywords and returning URL addresses. Even Technical drawing could be translated into postscript or PDF and use a similar system. If we only store pointers it would be very little data (1Mb?) > 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 haven't quite made a decision on which database to use during construction most likely it will be Fox Pro. > 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? > I think any database is a good tool only if it has an easy enough interface that most people will be able to use it. It would be nice if we could access the database information through the WEB especially the documentation part. The database used for online/offline calibration and serial information should have some performance requirements so it will never be the bottleneck while trying to analyze or even worse take data. Also we definitely want the data to be accessible from analysis programs. It is not clear to me, we should have a single database to store both the calibration and documentat information.