CMS tracker silicon barrel prototype electronic logbook

Introduction

• to collaborate on the project in all its phases from building to monitoring.
• to share data

• to quickly and easily develop cross-platform applications at low cost
• Easy to use and no need for training!
• html is a far simpler GUI than Motif or Windows. It works with tags easy to learn instead of complicated library of functions. The interface is rather limited but for a broad class of applications is good enough.
• html also provides a powerful system to integrate traditional database applications
• the technology scales gracefully since in case of need, you can set up many servers working in parallel.

Some guidelines

• Separate the HTML user interface from the application and database logic.
• Have only few hand coded HTML pages and the rest should all be created on-flight from CGI scripts .
• In writing scripts use DCL only for the necessary tasks of extracting input data from VMS variables . For the rest use normal C,C++ or Fortran programs. These programs can be more easily ported to other machines.
• Keep the structure of the files which form the database the simplest possible (Ascii text files). Don't use HTML tags inside them, but if necessary, use simple tags to separate parts in the file.
• Then use CGI scripts to read the database files and present them in sophisticated way to the user.
• In order to allow easy processing from CGI scripts of multiple files of the database use meaningful and consistent names for the single files and the directories.
• Exploit the openess of Web applications avoiding to hard-code in hundreds of html pages Web tags that can be outdated in a few months. Instead replace them with a script in such a way that when you want to change some part of these documents, you need to change only a few print instructions in this (unique)script.
• Keep ready for future:(frames,client side clickable images,tables,client side scripts,Java,etc..)

The distributed data base

Half-module informations

Hybrid	Phi side	module id	problem channels	noise map
	Z side	module id	problem channels	noise map
Wafer	Phi side	module id	Operation Voltage	Igr,Vdep	problem channels	resistance map	capacitance map
	Z side	module id	Operation Voltage	Igr,Vdep	problem channels	resistance map	capacitance map
Assembling	Effective dimensions	Gluing problems
Bonding	shorted and/or disconnected channels	Bonding problems
Performance	Pedestal map	noise map	S/N distribution	Dead/noisy channels

Features of the data base:

• Distributed in around 5 labs (those who build the detector)
• Contains around 1000 half-modules each with around 1000 channels. Each half-module is described by the information contained in the table above.
• Some of the entries for each half-module are single files containing around 1000 values,one for each channel.
• Other files will be a list of problem channels
• The information concerning performance will change in time:you should expect here more than one file per module with new files added periodically.

The Web interface to the database

We have to decide for a format for the above information. My suggestion is to use simple Ascii files like this with lists of numbers also for histograms. These can be easily transferred and manipulated. These Ascii files are mostly produced automatically by computer programs.These can vary from lab to lab but they must in the end produce the same Ascii file. This is then processed by a CGI script that will produce the module description in Netscape.

The rest of the information is entered manually through a set of standard Web forms like this. These will produce a Ascii file containing the information in standard format.

Other Web forms will be necessary to present information which changes in time and is periodically stored . These script should allow the access to all history and the possibility to compare data.

Documentation on tracker

• Mechanical Cad drawings