Agenda

• A working discussion of GCRTrack and GCRSelect layouts flowchart class diagram
  • How do they fit into existing recon?
  • Inputs?
  • What do they do (i.e. what are the functional "boxes" in the flow chart)?
  • How do they talk to each other?
  • Outputs
  • Any other questions from Claudia and Fred (or anyone else)
• What next for GCRTrack and GCRSelect?
• Eric N. GSI analysis update

  Attendees

  Mark Strickman Claudia Lavalley Fred Piron Sasha Chekhtman Zach Fewtrell Eric Grove Andrey Makeev Benoit Lott Eric Nuss

Notes

GCR Recon Discussion

• Do we assume that GCR Recon will take place in a separate "pipeline" from normal processing?
  • Dedicated GCR pipeline Con:
    • On one hand, much of the processing (TKRRecon CalXtalResponse) is the same as normal events
    • Using same pipeline may mean that output could be in standard recon.root file (same file as normal events)
    • Dedicated pipeline means a new root file (GCRRecon.root) would be required (maybe same format as recon.root)
  • Dedicated GCR pipeline Pro:
    • Rerunning GCR alone is more difficult (especially a problem early on)
    • Full recon.root is quite large => alot of unnecessary reads
    • In general, retrieval from a smaller, dedicated GCRRecon.root file would be easier
    • GCRRecon.root could be merged into recon.root later if necessary
  • General consensus is that dedicated GCR pipeline is desireable
  • We need to talk to ISOC (Eduardo?) about their plans and how GCR calibration will fit in
• Sasha asks: What is the efficiency of the on-board filter? Will it produce nonuniformities vs energy that will bias our calibrations?
• GCRRecon Flow
  • Currently, CalXtalAlg (CalXtalResponse) -> CalRecon
  • For GCR, can we do CalXtalAlg -> GCRRecon or do we have to do CalXtalAlg -> 0TKRRecon -> CALRecon -> TKRRecon -> CALRecon -> GCRRecon (similar to curren recon)?
  • Do we need to find Z in GCRTrack? It's required for MIPfinder (since MIPfinder needs energy), but we may only need MIPfinder in track if we can't use TKR (Fred thinks Z might be useful in Track)
  • We may want to set flags in Track that get monitored by filters in Select
  • Benoit suggests a root macro "toy" version of code to study algorithms. Could also be a UserAlg. Andrey and Eric N.'s work to date are steps in this direction

GSI Analysis Status (see Eric N. presentation above)

• • Fred is creating a roottreeanalysis to apply Erics analyses to simulated data
  • Sasha is surprised at the pattern in layer to layer energy deposition using full calibration. Could layer indexing be wrong? He'll check. Could be that one end uses X0-X3,Y0-Y3, the other uses X0Y0X1Y1...
  • Sasha also points out potential problem from big diode to small diode xtalk, since for Si, LEX1 is heavily saturated meaning serious xtalk to HE. Could try same analysis with Carbon, where LEX1 would not be saturated, but Eric N. points out that beam spreading is a problem.

Actions

• Suggest refinements/changes to flow of GCRSelect (Fred et al)
• Redo GCRTrack boxes in flow chart (Mark)
• Redo GCRSelect boxes in flow chart based on Fred suggestions (Mark)
• Revise "ID and Copy" box to make understandable (Mark)
• Contact ISOC re work flow (Mark)
• Contact Tracy (again) re TKRRecon (Mark)
• Check on layer order in GSI analysis/calibration (Sasha, Eric N.)

Next meeting: Feb 15