Date

Attendees

Overview

Text in the excerpt box will show up in lists of meetings.Scientists for TCX review

Discussion items

TimeItemWhoNotes

Two scientists for TCX review

Jon Eggert

Julien Fuchs

Robin Marjoribanks?

Gianluca Grigori

Stefan Weber (sp)

(Nam's group)



Engineering vs. ops model decisions
  • What's a "configuration change" entail
    • Engineers did not include "moving a slim" in this when top-down ops model said we wanted to change configurations in 2 weeks. 
    • It would involve moving mirrors, but the project doesn't currently have in it the load-lock mirror inserters. So we're breaking vacuum 
  • Under what circumstances would we ever move a slim from one port to another?
    • The engineering team considers this a huge ask
    • A SLIM is 10x as heavy/bulky compared to payload
    • SLIMS are above each other- more than one gets removed to get to a bottom one
    • Cables and vacuum run to them.
    • An endpoint would be 21 slims (all imagined) on the chamber at once
    • KPP objective of 9 means that there's something above configuration change, like configuration set change, or something – this could take a long undetermined time (say 2 months?)
  • Would we trade diagnostic stability off for some ability to easily swap SLIMs?
    • Making the above easier could compromise the vibration damping / rigidity structure
  • Vacuum pumpdown: speed vs dust scattering.
    • NIF requirement of Reynolds number of 1000 or better means realistically that a full chamber pump down takes 8 hours. To get from 1atm to 1 torr.
      • Corey notes that this requirement is 10x stricter at DESY
      • Early NIF experience was too much dust/damage  
    • ELI has a bigger chamber and pumps out in 30 minutes- they are clearly ignoring the above.
    • Dust on optics risks faster damage
    • We might question the air content of Al and whether shooting 1gm/hr could provide a meaningful "leak" rate.  
    • We would also want a certain slow pump down time for certain free standing membranes



FMEA system
Technical integration has an alternative to the risk registry to capture risks that don't directly affect the project itself.
The project risk registry is here. These should be risks to achieving CD-4.
We're more concerned with what happens after. So Kai's team made us an FMEA system. Currently capturing risks and operational cost items in a spreadsheet, here.
  • Currently Eric has a tab. We can all add comments to cells there for Eric's benefit OR
  • If interested enough, get your own tab to work on and directly add brainstorming
  •