04 Dec 2001CMS Week - Bonding WGSalvatore Costa - Catania Writing Bonding Data into the CMS Tracker Construction Database Salvatore Costa University and INFN – Catania

04 Dec 2001CMS Week - Bonding WG2 Salvatore Costa - Catania Sample DB Table INDEX VAR (integer) VAR1 (integer) VAR2 (float) VAR3 (vector of int) VAR4 (vector of float) VAR5 (string) Module id blah Module id foo Test Struc id1 ……………

04 Dec 2001CMS Week - Bonding WG3 Salvatore Costa - Catania Bonding-to-DB Tasks Define list of data to write –Initial proposal (now) –Feedback from centers (by end of next week) –Form consensus Create Bonding Tables in the DB Setup User Interface: –Choose software technology (done) –Create interface package (in progress) –Implement suitable access control (in progress) –Deploy according to an organizational model

04 Dec 2001CMS Week - Bonding WG4 Salvatore Costa - Catania Preliminary Data List From: –Alan’s Bonding Procedure doc (h.home.cern.ch/h/honma/www/Bonding/bondingproc pdf) –Witnessing a simulated bonding operation –An exchange of messages between me and Alan Broken into: –Data common for all centers –Data that may be machine (center) dependent –Pull test results

04 Dec 2001CMS Week - Bonding WG5 Salvatore Costa - Catania Common Data DescriptionNameData TypeEntry Mode Bonding CenterBOND_CENTERSTRING(128)CHOOSE FROM LIST Pre-bonding operator name PRE_BOND-OPSTRING(128)CHOOSE FROM LIST Pre-bonding (data entry) date& time PRE_BON_TIMEFLOATAUTOMATICALLY FROM SYSTEM Status found in pre- bonding inspection PRE_BOND_STATUSSTRING(384)TYPE-IN Post-Bonding operator name POST_BOND_OPSTRING(128)CHOOSE FROM LIST Post-Bonding (data entry) date& time POST_BOND_TIMEFLOATAUTOMATICALLY FROM SYSTEM Status found in post- bonding inspection POST_BOND_STATUSSTRING(384)TYPE-IN Channels not bondedNON_BOND_CHVECTOR OF INTTYPE-IN Recommended repairsBOND_REPAIRSSTRING(384)TYPE-IN

04 Dec 2001CMS Week - Bonding WG6 Salvatore Costa - Catania Machine-Dependent Data DescriptionNameData TypeEntry Mode Air pressureAIR_PRESSUREFLOATTYPE-IN Loop mode, height, pull up, pull over, pull down, pull off LOOP MODE, HEIGHT, PULL UP,PULL OVER, PULL DOWN, PULL OFF INTEGER(S)TYPE-IN Z speedZ_SPEEDINTEGERTYPE-IN Test heightTEST_HEIGHTINTEGERTYPE-IN Search Speed (1st, 2nd)SEARCH SPEED_1, _2INTEGER(S)TYPE-IN Bond Force(at both ends) BOND_FORCE_1, _2INTEGER(S)TYPE-IN Bond Time (at both ends)BOND_TIME_1, _2INTEGER(S)TYPE-IN Bond Ultra Sound (at both ends) BOND_U_S_1, _2INTEGER(S)TYPE-IN

04 Dec 2001CMS Week - Bonding WG7 Salvatore Costa - Catania Machine-Dependent Param. Let me quote Alan: “I would suggest that each center decide what machine parameters are worth recording and either come to you with a request for center-dependent data base entries or make their own DB.” “In the case of a center that does a variety of different bonding jobs (like CERN), it may be necessary to have the list of machine parameters for CMS module bonding to be part of their procedure (checklist) so that the operator can verify that the machine is set up correctly for bonding CMS modules.”

04 Dec 2001CMS Week - Bonding WG8 Salvatore Costa - Catania ND-Pull Test Results Done only on Test Structures Do we want to record these in DB at all? –If we do… DescriptionNameData TypeEntry Mode Number of pullsN_PULLSINTEGERTYPE-IN Failed ChannelsFAIL_PULL_CHVECTOR OF INTEGERS TYPE-IN Failure typeFAIL_PULL_TYPEVECTOR OF STRINGS(?) CHOOSE FROM LIST 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

04 Dec 2001CMS Week - Bonding WG9 Salvatore Costa - Catania Bonding Table Creation Not done yet Will start after consensus reached on a (preliminary) set of variables to write DB Group (Contardo et al.) do not create Tables. They provide GUI to create Tables and rules to comply with about their formal structure Their general guideline to WGs is to create a single table per “operation” and aggregate them into a “composite” that might be queried as a whole  “Pre-Bonding” Table“Post-Bonding” Table “Machine Parameters” Table“Pull Test” Table The “Bonding” Composite

04 Dec 2001CMS Week - Bonding WG10 Salvatore Costa - Catania User Interface Constraints to the design Software technology Interface package Access control Organizational model

04 Dec 2001CMS Week - Bonding WG11 Salvatore Costa - Catania Interface Design Constraints 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 Database WG strongly discourage frequent insertion of tiny bits of data, let alone data that hold valid for only brief periods of time. They want users to gather meaningful blocks of (reasonably) stable data before uploading them to DB.

04 Dec 2001CMS Week - Bonding WG12 Salvatore Costa - Catania Software Technology I propose to adopt a Graphical User Interface which uses the Electronic equivalent of paper forms: …linked to… …which write, update, and eventually upload into DB Such a package must run on Unix machines Web Browser Forms Perl scripts “local” files

04 Dec 2001CMS Week - Bonding WG13 Salvatore Costa - Catania Bonding-to-DB GUI Web Page

04 Dec 2001CMS Week - Bonding WG14 Salvatore Costa - Catania 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 N centers : –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).

04 Dec 2001CMS Week - Bonding WG15 Salvatore Costa - Catania Organizational Model The whole interface package can be deployed and maintained in 2 different ways, corresponding to 2 different organizational models for its maintenance: 1.Central 2.Distributed

04 Dec 2001CMS Week - Bonding WG16 Salvatore Costa - Catania Central Model CHANGE/ADD ENTER VIEW CT Center 1 dirs VALIDATE Center 2 dirs Center 3 dirs File system in CT daily cron job Backup copy to different disk Translation to XM » Upload to Lyon

04 Dec 2001CMS Week - Bonding WG17 Salvatore Costa - Catania Distributed Model CHANGE/ADD ENTER VIEW C1 VALIDATE Center 1 dirs daily cron job CHANGE/ADD ENTER VIEW C2 VALIDATE Center 2 dirs daily cron job Backup copy to different disk Translation to XM » Upload to Lyon Backup copy to different disk Translation to XM » Upload to Lyon

04 Dec 2001CMS Week - Bonding WG18 Salvatore Costa - Catania Model Comparison 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