Participants: Luca Latronico (LL), Philippe Bruel (PB), Benoit Lott (BL), Johan Bregeon (JB), Berrie Giebels (BG), Taka Tanaka (TT), Hiro Tajima (HT), Leon S Rochester (LSR), David Paneque (DP), Gary Godfrey (GG), Alex Moiseev (AM), Monica Brigida (MB), Claudia Monte (CM), Francesco Longo (FL), ....
PSF studies - Taka
I missed most of Taka's talk, apologies, but slides are good to follow
PB: about slide 6, you should know that there is a table induced shift that could be responsible for this, you can correct that
LSR: about slde 12, there are a couple of reasons why the wings of the distribution might not be symmetrical:
- the 'fish-eye' effect. This is a result of the tracking efficiency decreasing at large angles. A track which reconstructs at a smaller angle is more likely to be reconstructed than one at larger angle.
- The track fitting is with respect to the slopes, that is, the tangents of the angles, not the angles themselves. This could bias the distributions (but I'm not sure of the sign!).
Both these effects are bigger at large angles and low energies.
TkrHits and Cal Energy - Johan:
JB: recently realized that I was running with a non correct hadron simulation library link that made the photon evaporation process not taken into account
FL: wrong link to library for windows. must fix this for next GR, fixed in BTRelease. Not a bug, just an issue with windows based links. Suggested to Navid how to do it and he will do it.
BL: photon evaporation is a wrong name, photon emission is the correct name. I am surprised that energy that goes into a photon does not go into charged particle eventually
JB: to avoid confusion, this just happened in my new run, it was not the case for pipeline runs
slides 4-5: MC produces same nb hits for 5GeV pi and 150GeV p, whereas data are different. Used stringent cuts on MIPs and requires less than 140MeV in CAL to remove backsplash events that may not be perfectly modelled. This shows MC has strong problems in my view
6: comparison of stdalone CAL sim with data and beamtest sim. surprisingly stdalone sim matches quite well data, this is not the case for our BT sim. Please take into account that stdalone sim does not have description of realistic CAL geometry, so absence of cracks might explain higher deposited energy. Still, the agreement is strange.
7-8-9 are combined from previous talks of mine, combining data, std and QGSP models. Interesting to notice how well the energy deposit is modelled by QGSP, even on a log basis, although CalTransRms is not good
10: conclusions just read them
LL: thanks, let me suggest we have a little discussion on the prospects here. In particular, can you make an estimate of how long it would take to improve on the stdalone simulation and link it to beamtest06?
FL: I suggested to improve/check on the way we deal with the nb of simulated particles..... not hard anyway.
BL: what is the rationale? if we make stdalone as complicated as gleam, what is the point
FL: johan tried the stdalone to test realistic tkr honeycomb. so tkr geo is in there. also a simple cal gem was attached. shooting g4 particles in such model you get data profile. the conclusion is that g4 alone is fine.
BL: trying to summarize what we had from stdalone sim (various people did this job), we know that g4 is fine. so we do not expect to find reason for discrepancy there. also beamtest06 is fine as GR simulations did not reveal any difference with beamtest06 ones.
LL: agree with benoit, the point here is to check geometry, the only element that was not isolated before, you can do it by making the stdalone sim geometry close to the gleam one or by checking gleam in an independent way
BL: good to double check everything, but I am skeptical to find anything from sheer geometry
PB: isn't the stdalone sim with a deeper cal geometry?
JB: true it is about 10X0 so you might expect some backsplash from layers below
PB: the fact is that you should expect some 4% more energy in the stdalone sim wrt to BT sim, just from comparing thicknesses and gaps. I am surprised by this bigger difference (8-9%), also you would expect more energy than in data since you have no gap between logs.
JB: was surprised myself too, need to work and understand why.
LL: anyway I have the feeling johan will do some more work on the stalone sim and will report to the group
Crystal segmentation - Philippe
PB: trying to understand the CAL geometry I learnt that each log is segemnted in 12 pieces, my understanding is that this is a trick not to store too much info since you have to take into account light tapering. So each log is divided into 12 segments. You use mean and average of each segment and derive the energy of the xtal and the position measurement. I tried to change the nb of segments in geometry db from 1 to 100 to see if there are consequences on energy or position measurements.
1GEV: top row is mean of deposited energy vs nb of segments, same for positions. Discovered that you cannot set segments higher than 63 because of initialization of a variable, so I limited the scan to 60 for 10 and 100GeV
10GeV plots and 100GeV plots: no significant change with nb of segments. disappointing, as you might think that since our discrepancy is angle dependent, this would have been a good reason.
LL: again recommend to look into CsI thickness, remember the TKR case when only during the BT analysis we realized that the geometry db was not updated with the real tiles thickness after the etching that was necessary during construction
PB: I was checking the geometry and checked an heprep representation of the geodb, that is how I discovered the segmentation
BL: the xml file I often use only has a single value for cal log thickness
LL: I am thinking more to something similar to the TKR, where the actual value in the modules is different from the one in the geo db
BG: I found nothing wrong in the xml file. Remember we also had a material review 1-2 years ago and the average measured value is the one stored in the geo db
MC discussion
LL: recently fixing bugs for hadronic physics list access and merit files event loops. Johan is collecting requests for new MC runs, he has some from David and Bari, he will run those simulations on the pipeline
JB: some of David runs are ready, just email me and I will produce requested runs
LE tagged photons PSF
LL: analyzed LE tagger configuration runs and produced some PSF plots for vtx and single track events. The point I want to make is that these runs contain good data, I have corrected the wrong computation of the error associated with the photon energy measurement from the tagger and will fwd it into next BTRelease. This is probably good for energy resolution measurements too. PSF plots are preliminary