May 23 2007
Participants
Luca Latronico (LL), Nico Giglietto, Tomi Ylinen (TY), MarioNicola Mazziotta (MNM), Jan Conrad (JC), Gary Godfrey (GG), Johan Bregeon (JB), Benoit Lott (BL), Hiro Tajima (HT), Leon Rochester (LSR), Eliott Bloom (EB), Yvonne, Bijan Berenji, Francesco Loparco, Monica Brigida (MB), Francesco Longo (FL), Elena
update on hadronic models
JB: update on hadronic cascade work. new cmparison with special models, in particular QGSP model at high energy (>150GeV), with a set of comparison of merit and svac variables, including CalTransRms
slide 2: description of data, hadronic interaction models used, also tried QGSP_BIC (not shown) and it gives similar results to QGSP_BERT. all the plot data are black and MC in red. cuts are discussed here. remember that for merit there is no access to Dt variable.
you can browse following plots by yourself, few comments I want to make:
slide 4: striking that raw variables are quite well reproduced, but caltransrms is quite a bit shifted; this variable has a surprising behaviour, if you look at high energy, where the QGSP model well reproduce raw variables, caltransrms is not well reproduced
LL: can somebody remind how is CalTransRms calculated? it is strange that log hit and energy are well reproduced and caltransrms is not ...
BL: this was recently discussed, trajectory is calculated and the dispersion wrt to average trajectory is CalTransRms
LSR: it is weighted with energy, sort of rms energy-distribution around trajectory
JB: page17-18 caltransrms well reproduced with GLAST while the other variables are not, the opposite is true for QGSP (slide 19-20), so there is really something special for CalTransRms
JB: seem to remember that francesco reported that CMS also finds QGSP model giving better reproduction of data at high energy; in particular CalEneSum histo almost perfectly reproduced in page 1 for QGSP - it is remarkable that agreement extends all the way to 50GeV and we still have a discrepancy in the data/MC agreement for EM showers, not sure how to interpret this, but it is intriguing; one might think that we really have a problem in the description of EM shower development
AM: tkr1rms is not well reproduced, and what are the two peaks in the second peak?
JB: did not try to cut on that variable and on peak to try and identify these events; plots I showed last time also show another TKr variable with a different behaviour, a sharp cut. I use the same release for data and MC
AM: could it be a bug? no physical explanation for that?
LSR: can you remind what that variable is measuring?
JB: Tkr1RMS is from svac, i think it is the rms distribution of hits around the 1st track
BL: what are the units? hits cannot be fractional
AM: could be interacting events
LSR: it would be my guess too, some kind of hit RMS, but I need to see how that is calculated; the so called interactive events have and RMS that is broader
AM: data look more reasonable than MC here right?
BL: the difference is not the same for 100 and 150GeV, it maybe connected to the beam spot
JB: I applied cuts (more than 8 logs and 200MeV) to select all interacting events. i agree it could be a leftover beam spot parameterization, will investigate
LSR: in particular the low peak appears around 150GeV
BL: seems that cuts are not homogeneous with energy, nb hit log shows a peak at 8 at 150GeV (MIP), not at 100GeV
MNM: it seems there are more clusters in MC than data, do you know why?
JB: answr to Benoit: i have used same cuts all over, except for the 150GeV plots, I realize I have put the wrong plots where I cut requesting only more than 4 logs (so including MIPs, that are shown in the plot). answer to Nicola: i don't know
MNM: which MC version?
JB: latest BTrelease with my hadronic lists
MNM: does it include new TkrDigi?
JB: not sure about version
JB: last slide - suggested hadronic list is bertini up to 10GeV and QGSP above 20GeV. CalTransRms issue remains open. need more statistics from pipeline MC. room for beam spot description improvement. started looking at angled runs. should put more MC on same plot for combined comparisons
LSR: BTR v6r0925 is based on GRv9r25, but includes latest TkrDigi, so these data include chargesharing, how it increases clusters is not clear
MNM: did you not change the actual threshold for strips to fire?
LSR: true I did, well did anyone look at electrons? maybe they are fixed too ...
JB: may be due to specific behaviour
LL: also interesting to note that CTBCORE is well reproduced - I don't know if the values are meaningful, but we always thought that becasue of gemoetry CT variables would not be significant for the CU, maye we should try to cut on CTBCore to compute PSF
JB: actually it would be interesting to run a simple p beam using glastrelease for the LAT and see how CTBCore look like
Discussion on MC production
LL: we sholud discuss generation of new MC runs. There will be more hadronic interaction model runs, and runs to check the effect of changes from updates on TKRDigi, both from Leon and from Bari. Idea is to proceed with specific runs to cover all items and only eventually move to mass simulation again. In the meantime Johan learnt how to operate the pipeline. He has summarize the status of his training and has a proposal to discuss
JB: sorry you have to hear me again.
before I start let me mention an issue that circulated in the mailing list and raised by Nicola, who finds problems when looping on events from svactuples; JCT found a bug, fix should come in next release
JB: for new MC production the proposal is to proceed by user request (email to beamlist) before we move to mass simulation.
need to work on beam spot parameters, I link to my script to run MC at SLAC w/o pipeline - can be run from your area
should maintain a database for beam spot parameters (confluence/txt file on CVS). will check with David
LSR: wrt to bad events, rejecting bad ones will cause bad synchronization between merit and svac and output root files
LSR: we could make a patch in filterAlgTuple, but it would be a patch on a branch
MNM: problem happens only with fullbrem runs - maybe can just reprocess them
LL: not sure, we have not systematically tested all runs
JB: heather said it is a known bug cured by some new code, LSR should know more
LSR: at some point reorganized and moved the code from OnboardFilter/FilterAlgTuple to AnalysisNtuple/ObfValsTool. At this point the undefined variables were fixed.
LL: this is quite technical, michael, leon and heather working on that, we will find a solution. For the MC I want to add that I and Philippe will make sure that the analysis that people are pursuing have the latest MC production, at least for a sample of significant runs. Francesco I see you managed to connect, do you want to add anything for MC production?
FL: only thing I want to report is that I need to do some check to understand if and where in beamtest06 there is a problem causing the divergence found by David for beam spot of full brem runs
LL: ok thanks, we will circulate MC run request through the beamlist and talk again in 1 week