• Available trigger engines are such that we must add TKR trigger requirement to Andrey's simulations
  • We need to consider the on-board filter in much more detail!
    • Current filter knocks out many GCR events
    • CNO only rate is at least a factor of 5 higher than Steve R. is willing to allow
    • Richard Hughes and Co. are trying to increase throughput of useful GCR events
    • Need to add filter status word to Andrey's output products, so we can investigate in detail what the filter would do to events
  • Charge sharing for GCR tracks in TKR is potentially an issue and may cause more hits than delta electrons
    • Issue for hits gt 15 MIPS
    • Robert Johnson has volunteered to model this with a SPICE simulation. He thinks he can do this pretty accurately
    • Only way to measure before launch would be to take a TKR to GSI. Desirable but not likely
  • For several reasons, delta electron effects might not be right in sim or analysis
    • Check Andrey's analysis carefully - clearly Fe should produce more hits than C (or so it would seem)
      • Look at events in FRED
    • Francesco has questions about whether delta electrons are simulated adequately in G4, especially for thin layers in TKR
      • Need to run some relevant tests to look for reasonable production, spectrum, angular resolution (e.g. iron into single thin layer with delta elec. production recorded)
    • Leon has done the following tests
  • We need an error budget for GCR calibration. This will allow us to assess, for example, what precision we require for path length correction, which, in turn, addresses whether or not we require the TKR
    • Mark will try to write an error budget note, outlining contributions. Then we'll divide up individual tasks
    • Please forward your favorite error sources to Mark!
  • Quenching
    • How do we extrapolate quenching curves to GCR energies?
    • If we decide that we need to access quenching vs energy in general (as opposed to assuming it is constant except for Fe - see below), what do we use for ion energy?
    • For Fe that slow down, we certainly need to attempt to track quenching vs energy. Energy from dE/dx sequence?
    • Contribution to error budget
    • Store quenching data as XML in LATCalibRoot? Access via calibutil code or write our own?
  • S/W architecture
    • GCRTrackRecon and GCRSelect will be part of GR
      • Have to be algs (not tools) since algs are easier to pilot from jobOptions file
      • They will be eventually included in CalRecon (no additional package), and CalRecon could decide whether or not to call them
    • No additional ROOT file: GCRTrackRecon will add its outputs to the recon.root file
    • Pipeline:
      • Still in discussion : this does not prevent from starting developping the 2 algs in a flexible way (especially GCRTrackRecon outputs and GCRSelect)
      • Has GCRCalib to be part of GR ?
        • Pros: pipeline will have to include monitoring, quick-look analysis, etc.. so GCRcalib could be part of CalRecon and of normal pipeline
        • Cons:
          1. A standalone code like calibGenCal reads ROOT files faster (no need for a GAUDI ROOT-TDS converter)
          2. GCRcalib will essential do diagnostics, histogramming and fitting, and does not need GAUDI services
          3. Code modifications are easier if not in normal pipeline
  • No labels