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)
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:
A standalone code like calibGenCal reads ROOT files faster (no need for a GAUDI ROOT-TDS converter)
GCRcalib will essential do diagnostics, histogramming and fitting, and does not need GAUDI services
Code modifications are easier if not in normal pipeline