ILC Cavity Data Management

1. ILC Cavity Data Management Final Report June 11, 2007 Peter Kasper

2. Team Members • Jamie Blowers • Denise Finstrom • Peter Kasper (leader) • Michele McCusker-Whiting • Janice Nelson • Jerzy Nogiec • Joe Ozelis • Marc Paterno • Claude Saunders

3. Charter: The Problem • The US effort on fabricating and testing SCRF cavities and cryo-modules is occurring at numerous sites across the country, and each is handling the management of cavity-related process data in their own way. In addition, some sites (e.g. Fermilab) have numerous different sub-organizations working on cavity processing, and each of these is also handling data management in their own way. The result is that much data is being generated, but it is spread throughout numerous systems. This lack of data organization results in the inability to easily locate all data related to a specific cavity and cryo-module. This can then lead to numerous problems, one of which is the inefficiency at best, and inability at worst, to be able to appropriately use the data for understanding the technology and for making improvements.

4. What We Did • Examined existing cavity database systems • Pansophy (JLab) • DESY • Looked at a commercial option • Tecnomatix (UGS) • Produced a “Requirements Document” • Evaluated options against requirements • Functional and technical assessments

5. Tecnomatix – Not recomended • Looked promising when demoed • Licensing costs looked prohibitive (but negotiable?) • $2K for each report client user • Tried to set up an evaluation • Cost ~30K in consulting fees • Took too long to negotiate • UGS bought up by Siemens!

6. Functional Assessments • Supported input methods • Representative reports • Ad hoc (user defined) reports • Cavity process history • Process details • Cavity performance history & snapshot • Cavity discrepancy report • Component genealogy • Correlate performance with 24/7 monitoring • Production tracking

7. Technical Assessments • Schema style • Software technology components • Security features • Integration API • Learning curve/training • Database independence • System support • Licensing

8. Pansophy • Stongly process oriented • JLab chose to create Pansophy rather than adopt the DESY system partly for this reason • Schema design creates severe problems that get worse with time • Difficult to provide automatic data entry • Difficult to maintain, modify, and create reports • Some (unnecessary) licensing costs

9. DESY • Weak process integration • Unable to produce process related reports • No access to process details or discrepancy reports • Unable to produce a production activity report • Complete dependence on Oracle is a major weakness • Lack of database independence • High licensing costs

10. Conclusions • Both options require significant work to make them comply with the requirements • Comparable effort to starting afresh • Pansophy is the solution that is closest to meeting our needs • The current form has design flaws that … • Make it difficult to maintain over the long term • Make it difficult to share data with other systems

11. Extra information • DESY system is being reworked to • Replace a graphics package that is no longer supported by Oracle • Improve the schema performance • JLab wants to produce a new version of Pansophy that fixes its design flaws • They are keen to collaborate with Fermilab in this • It is not clear how extensive are the changes that they are planning

12. Recommendation • If possible, negotiate a collaboration with JLab to rework Pansophy into something that meets our needs • Otherwise produce a merger of the DESY and Pansophy concepts • Use open source technologies • Estimate 6-9 months for working system