1. 1 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Current Module LT Testing Capability Only Vienna Boxes Available  10 slots at each site  ~75% efficiency of running time Will estimate the amount of time run per module with:  50,100 module tested at each site  1 month, 2 months, 4 months run periods Will assume 1 week at end to pull together results and 1 week lost to produce modules, procure & test module components, etc.

2. 2 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Current Time Estimates Time1 Month2 Months4 Months 50 Modules2 ½ Days7 Days16 Days 100 Modules1 ¼ Days3 ¼ Days8 Days To run 100 modules for ~week each will need either: Both sites running for ~2 months 1 running for ~4 months Any production beyond the 100 modules mentioned disrupts this test significantly Any new modules would have to be put into Vienna box for testing as rods will not be available at rates to burn-in on rods Thus, more modules could be run, but for less time Even more time lost to loading/etc. How long do we want to run the modules? Modules Per Site

3. 3 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Way To Increase Modules Run Run modules on rods in rod burn-in box  To get statistics needed (~100 modules), use 16 single sided rods Use of DS rods will not increase statistics; DAQ hardware max-ed out at 8 SS4 rods  Two fully equipped/functional rod burn-in boxes Or multiple runs with smaller number of rods Calculate time run assuming:  2, 4, or 8 rods per box DAQ components for 2 rod running should be available at end of December  4, 5, or 6 month periods from today Assume 3 months to commission system to point that it is safe enough to run unattended and assemble 16 rods  Assume 75% efficiency once stable  Very aggressive, assumes that software and hardware works almost immediately and that system scales from 1 to 8 rods with no major problems  10 more cabled rods available late Jan./early Feb. Assume 2 weeks total to pull together results after run THIS SCHEDULE IS EXTREMELY AGGRESSIVE AND HAS NEVER HISTORICALLY OCCURRED IN SIMILAR SITUATIONS

4. 4 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Rod Burn-in Time Estimates Time4 Months5 Months6 Months 2 Rods3 Days8.5 Days14 Days 4 Rods6 Days17 Days28 Days 8 Rods12 Days34 Days56 Days To get more significant running time per module (2 weeks) Need 6 months with 2 rod per cycle capability Need 5 months with 4 rod per cycle capability Need 4 months with 8 rod per cycle capability If a month per module is preferred, need 4-8 rod per cycle capability in order to finish test in time period given Would take significant manpower, hardware increases, and software and data analysis development Takes resources from other commitments: TOB/TEC hybrid PA wire bonding/testing, starting TEC module production, ramp up of TOB module production, finalization of module LT setups Rods Per Cycle

5. 5 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Difficulties in Rod Burn-in (Hardware) Assumes equipment/hardware we do not have yet:  12 assembled rods  PS cables  2 rods per cycle still need: 2 Delphi LV PS 2 OFED (2 OEC each) 2 oMUX crates with 3 oMUX each  4 rods per cycle still need: 6 Delphi LV PS 4 OFED (2 OEC each) 2 oMUX crates with 5 oMUX each  8 rods per cycle still need: 14 Delphi LV PS 8 OFED (2 OEC each) 4 oMUX crates with 5 oMUX each Recent/imminent deliveries of:  All oMUX  All OFED Parts and test equipment limit number of rods usable  Assembled rods 10 more rods late Jan/early Feb Rest in late Feb  Delphi LV PS 5 total for tracker in Dec. 5 total for tracker in Jan. 12 total for tracker at end of Feb. Rest in April To do significant number of rods would require majority of Delphi LV PS built  May have to “borrow” existing supplies from current sites

6. 6 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Difficulties in Rod Burn-in (Software) Assumes software we do not have yet  LT only shown to work on 1 rod May not be easily expandable to number of modules needed (Multiple oMUX crates, memory, etc.) May require significant fraction of Wim’s and Valery’s time  Single rod commissioning/ validation software not developed yet Do not have algorithms to do fault finding  Software to monitor/find changes in module response during module burn-in does not exist yet Similar rod software would have to follow the module software  Rod burn-in slow controls/interlocks have not been commissioned with rods yet Integration beginning as we speak

7. 7 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Difficulties in Rod Burn-in (Manpower) The same personnel at UCSB/FNAL would have to be used for:  Testing/assembly of modules/rods for this study  Begin TEC module construction/testing  Begin TOB/TEC hybrid testing  Construction/commissioning rod burn-in stand Development in stages due to lack of rods and power supplies The same personnel needed for software development  Module LT analysis  Rod commissioning  Rod burn-in software  Rod burn-in analysis

8. 8 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Conclusions (1) The rod burn-in stands needed to run large number of modules for a significant period of time Such a program would require a commitment of a large fraction of the resources needed for sub-structure assembly/testing  (Almost) all the Delphi LV PS in community  Large fraction of testing manpower at UCSB/FNAL  Most of the software developers time This commitment will leave few resources for other tasks  Hybrid/module production and testing  TEC module production in US If everything delivered on schedule and works perfectly, earliest we could get 100 modules run for 1 month each would be April  This assumes 8 rod burn-in assemble and commissioned at both sites starting late February  This assumes 4 complicated software packages will developed and commissioned in the same time frame

9. 9 Long Term Module Testing-Anthony AffolderTPO, December 11, 2003 Conclusions (2) From historically similar situations  It is not likely that all equipment needed will arrive in the time needed  It is not likely that all the software needed will be developed in time From this experience I would assume that we could run 100 modules for an one-month period by June/July/Aug  I do not have enough information now to make a more precise estimate  Each equipment piece (2 types) and software package (4 types) can easily be delayed by a month easily