1 / 18

Writing Bonding Data into the CMS Tracker Construction Database

Writing Bonding Data into the CMS Tracker Construction Database. Salvatore Costa University and INFN – Catania. Sample DB Table. Bonding-to-DB Tasks. Define list of data to write Initial proposal (now) Feedback from centers (by end of next week) Form consensus

apu
Download Presentation

Writing Bonding Data into the CMS Tracker Construction Database

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Sample DB Table

  3. 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

  4. Preliminary Data List From: • Alan’s Bonding Procedure doc (h.home.cern.ch/h/honma/www/Bonding/bondingproc011104.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

  5. Common Data

  6. Machine-Dependent Data

  7. 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.”

  8. ND-Pull Test Results • Done only on Test Structures • Do we want to record these in DB at all? • If we do… • 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

  9. 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  The “Bonding” Composite

  10. User Interface • Constraints to the design • Software technology • Interface package • Access control • Organizational model

  11. 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.

  12. 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

  13. Bonding-to-DB GUI Web Page

  14. 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).

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

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

  17. 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

  18. 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

More Related