...
- 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)
- On one hand, much of the processing (TKRRecon
- 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
- Dedicated GCR pipeline Con:
- 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