Writing Bonding Data into the CMS Tracker Construction Database

1. Writing Bonding Data into the CMS Tracker Construction Database Salvatore Costa University and INFN – Catania

2. A Bit of History • I volunteered to take care of DB entry for the Bonding WG in Nov 2001 • I had an initial proposal ready for the 4 Dec 2001 Meeting but was unable to get to Geneva • Turned presentation into a Web document whose URL Alan sent to everybody • Gathered only Alan’s (extensive) comments I’ll present here an updated proposal that takes into account Alan’s comments

3. Organization of the Talk • Unlike what you may have seen in my original proposal’s Web doc, today I’ll first • Describe the software interface for writing Bonding data into DB • Then • Present the current (proposed) list of data to write into DB

4. User Interface Architecture • Design background • Design motivations • Software technology • Interface package • Access control • Deployment

5. Interface Design Background (1) • The Tracker DataBase WG (Contardo et al.) provides a DataBase environment for permanent storage of Tracker construction Parameters (TrackerDB) in Lyon. • It is up to individual WGs to: • decide which data to store into TrackerDB • create the relevant Tables • devise a suitable procedure to upload data into TrackerDB • TrackerDB is meant for retrieval of detector characteristics in the years to come, as well as for information flow between one WG and the next as construction progresses. • TrackerDB is not meant for storage of temporary or ephemeral pieces of data while some operation is in progress; for this, WGs are encouraged to develop their own intra-WG information flow systems.

6. Interface Design Background (2) • In general, to see data already existing in TrackerDB (e.g. from WGs whose operations occurred before Bonding, such as Sensors) one has to query TrackerDB using an interface provided by the DB WG (called BigBrowser) • However, I’m investigating if I can provide this functionality from within the interface I’m writing for the Bonding WG. • TrackerDB already provides for entry of Shipping/Receiving data at Institute level (through BigBrowser). • This does not apply to shipping/receiving from a given operation at an Institute. Thus individual operations such as Bonding may want to include receiving and shipping info as part of their own data.

7. Interface Design Background (3) • To write Bonding data into TrackerDB, following the Sensor WG, I foresee a 2-step process (motivation on next slide) • 1st step: Bonding Operators write data to a “local” HTML file (localto the Bonding WG) • 2nd step: Local HTML files are translated to mandated XML and uploaded into TrackerDB in Lyon. • The 1st step is performed by an easy-to-use Web interface (which triggers sophisticated scripts which run behind the scenes) • The 2nd step is performed by “smart” scripts (i.e. they know when to act) which also run behind the scenes.

8. Interface Design Motivations • Unlike other WG operations, Bonding does not produce automatically any computerized data All data must be entered manually • The bonding operation (on a given module) may occur in different installments, carried-out by different operators • Data first entered may undergo changes as the operation (on the same module!) progresses Example: non bonded channels

9. Software Technology I propose to adopt a Graphical User Interface which uses the Electronic equivalent of paper forms: …linked behind the scenes to… …which write, update, allow to view… …and eventually translate & upload them into DB Such a package must run on Unix machines, but Users can sit in front of any computer with a Web Browser in any part of the world Web Browser Forms Perl scripts “local” HTML files

10. Bonding-to-DB GUI Web Page

11. Access control • Why: • Interface is on a URL: world accessible • How: • No control on the front page or to VIEW bonding data • OPERATOR password to ENTER or CHANGE/ADD data • SUPERVISOR password to VALIDATE a module for permanent recording into DB • Both Passwords different for each center: 2 x Ncenters: • Passwords decided by center Responsible Persons, communicated to me, installed by me. • At each center, it will be the responsibility of the center Responsible to reveal either password to the appropriate person(s).

12. Interface Deployment The whole interface package can be deployed and maintained in 2 different ways, corresponding to 2 different organizational models for its maintenance: • Central • Distributed

13. Central Model VIEW Center 1 dirs ENTER Backup copy to different disk Translation to XML » Upload to Lyon Center 2 dirs CT CHANGE/ADD Center 3 dirs VALIDATE daily cron job File system in CT

14. Distributed Model VIEW Backup copy to different disk Translation to XM » Upload to Lyon ENTER Center 1 dirs C1 daily cron job CHANGE/ADD VALIDATE VIEW Backup copy to different disk Translation to XM » Upload to Lyon ENTER Center 2 dirs C2 daily cron job CHANGE/ADD VALIDATE

15. Central Pros: Easier for me to deploy Easy for me to maintain by just broadcasting any changes to all centers Cons: System unusable by all if CT goes down(one could use a printed form for a couple o’ days Distributed Cons: Deployment requires interaction between me & local sys admins and local configuration Maintenance requires local expertise and will lead to different setups among centers Pros: Failure only affects single center at the time Model Comparison

16. Interface Evolution • The interface may actually grow more complex,as Alan thinks Pre-Bonding, Bonding and Post-Bonding may be so separated in time and person doing them that it may be wiser to upload their info to TrackerDB separately. • In this case: • Front page will give access to VIEW and CHOOSE OPERATION (Pre/Bond/Post). • For each Operation the previously planned actions will apply (ENTER/CHANGE/VALIDATE) • Access control may be via 2 pw’s/center as now, or 6 pw’s/center (pre op, pre su, bond op, bond su, post op, post su), or just 3 (pre, bond, post) by merging op&su privileges for each operation.

17. Alternate Interface VIEW Center 1 dirs Pre ENTER CHANGE/ADD Backup copy to different disk Translation to XML » Upload to Lyon VALIDATE Center 2 dirs CT ENTER Bond CHANGE/ADD VALIDATE Center 3 dirs ENTER Post daily cron job CHANGE/ADD VALIDATE File system in CT

18. Software Writing Plan I plan to first • Write the Web-based interface (HTML files and Perl scripts) that write “local” files (already doing it) Then • Wait for experience to build up and modify interface (and already wrutten files!) as needed/requested When variables appear stable • Create Tables • Create programs that upload local files to TrackerDB • Upload all at once local files written thus far From then on • Upload local files to DB with the scheduled jobs

19. Bonding Table Creation • Will start after consensus reached on a stable set of variables • Following general TrackerDB guidelines, will have single tables per “operation”, aggregated into “composites” that might be queried as a whole  The “Bonding” Composite The “Bonding Repair” Composite

20. “Pre-Bonding” Table

21. “Bonding” Table

22. “Bonding” Table (cont’d)

23. “Post-Bonding” Table

24. ND-Pull Test Results • Done only on Test Structures (true?) ND D • List of possible values: • FBHB= first bond heel break • FBL = first bond lift-off • SBHB= 2nd bond heel break • SBL = 2nd bond lift-off • MSB = mid-span break • OTH = others, such as pad lift, cratering