Meeting 47: June 13, 2007
Participants
Luca Latronico (LL), Monica Brigida (MB), Takaaki Tanaka (TT), Hiro Tajima (HT), Philippe Bruel (PB), Benoit Lott (BL), Johan Bregeon (JB), Francesco Longo (FL), Leon Rochester (LSR), TOmi Ylinen (TY), Sasha Checktman (AC), David Paneque (DP), Sivia Raino (SR), Gary GOdfrey (GG), Elliott Bloom (EB), (MNM) Nicola Mazziotta
News
- Switch to evo from VRVS - test meeting june 20
- Collaboration Meeting Plans page
LL: we propose to prepare contributions on systematics induced by current discrepancies; this is in line with the aim of the meeting which should focus on analysis results, and should be coordinated with C&A
LSR: there was a discussion at core soft meeting about a bug that Tracy found in G4 library that could affect our hadronic sim, it is in the libraries, not in the G4generator, so basically not under CVS control, just happened sometime in march and it was just fixed. Tracy said he would report in this meeting later
LL: hope it does not screw up our agreement for QGSP models
JB: from vore minutes affects old version, so not sure if we area ffected
CAL energy measurement from last MC production - Philippe
PB: Did not repeat analysis, just looked at 100GeV e on axis, no big change, only change is that beam profile is smaller along Y direction and beam profile is better reproduced, but as expected it does not improve CAL results.
We sent an email about CalTransRms to beamlist yesterday with Johan, should have thought about it earlier, basically our beam is larger wrt to pencil beams through the LAT geometry and that explains the difference in CalTransRms, smaller for BT (edit by JB :100GeV em shower splash on several towers, using either the LAT or the CU06 geometry changes CalTransRms)
Energy profile and plots about Tkr1CORECH - Johan
JB: slide 2: I improved G4 simulation this week (geometry is now 8 layers and 12 comlumns with gaps), possibility to connect G4 stdalone sim to output of beamtest06 beamline sim.
slide 3: Comparison of G4 stdalone with simple beam (blue), same with beamtest06 particles (yellow), BT data (black), BT MC (red) for 5 and 10 GeV
comments: magical match from last week disappeared, all energy disappeared in gaps. Very good agreement with G4 stdalone + beamtest06 with BT MC (red and yellow). Excellent consistency check of what we are doing. From here different comments can be made:
- beamtest06 is doing its job
- adding material along beamline should shift the peak
- francesco suggest to work on beam line package to introduce extra photons
LL: these would be photons from interaction of the beam with collimators
BL: can wait for franz, but the idea of the discrepancy coming from the magnets can be ruled out from the beginning; if there was a problem with magnets it would creat a large asymmetry, there are several magnets located in many places, whatever contributes to magnet creates halo on one side of the beam, we have no hint that this is the case here. and we played with extra material along the line and this really changed the profile. extra material will not help solving discrepancy, in my opinion the only way is to change calibration constants
AC: which tower is this sim done for and what is the geometry for the stdalone sim?
JB: data in twr2, so BT MC done in twr2 with reasonable beam profile. G4 stdalone sim done with 1 full tower geometry with gaps, does not have C-fiber and no Al grid
DP: when you include dead material did you reduce xtal size?
JB: xtal size is what is defined in BTrelease, did not change it
AC: I checked xtal weight and dimension and get what we have in the xml file, so no error there
DP: just wonder where the energy goes?
BL: good question energy does not go away from CAL module, it should be detected by next log
JB: can investigate where the energy goes
PB: surprising when you look at 10 GeV profile from last time with solid cal, there is no hint of .....
JB: I was also surprised that the difference induced by gaps was so big
MNM: do you plot the real energy deposited in G4 or did you use any cal constant?
JB: just take enegy deposited in every step and sum it to get energy deposited per layer
MNM: yellow curve has same max as data, but less energy, so maybe a problem with calibration?
JB: in any case we have no other idea for changing calibration, maybe sasha can confirm
PB: when I compare energy in layers in data and MC, data/MC ratio is not constant, 20-30% in layer 0 then goes down to 10% and depends on energy and angle, so no way to have a single cal constant
slide4: following request from Bill checked Tkr1COREHC from merit, here described. nb of extra clusters wrt to those belonging to the track, and this is where our main discrepancy lie. Also chose another (random) varialbe to compare TkrSurplusHitInside (recommended from merit documentation rather than TkrNumHits), and again note these deals with clusters not hits!
5: compare these vars data (black) and MC (red) for p
6: same comparison for e, agreement is not too bad at 10GeV
LSR: slide 5, any sense for a lump at about 25 in MC which is not in data?
JB: guess it is a beam spot related issue, remember what I reported last time, did not have time to find good cuts on beam position
LSR: now i remember thanks
LL: francesco, can you tell us more about your proposal for playing with collimators in the sim to create secondary particles that would travel with the beam to get us more energy?
FL: not my suggestion, it is guido's suggestion in a BT meeting, he says that if there are photons together with the beam (interactions before the target) which travel together with the beam, you do not see anything with a full profile cal, but you would in our case. so no homogeneous material but simulate a non-homgeneous material at the side of the beam (butterfly shape like, more material at the side wrt to centre), so electrons with less energy in outer part of beam spot. I think it is worth trying this idea. He suggested that 90 degree analysis shows a better agreement, so this shows that a full containment cal is a difference. I have a counterargument from myself, if this is the case, the effect is different between PS and SPS, so we should evaluate the effect with as close as possible energies
BL: i already expressed some concern, I am a little lost here, is the photon related to the e (same event) or are those uncorrelated events?
FL: i need to check with guido, but I would think about correlated events
BL: in that case it does not change, collimators are very far away, it would screw up our distribution, could not be a dominant process
FL: agree with you, collimator location is crucial point, if they are far away the magnet should clean the beam, i think we should try as this is the last thing we can do
BL: David Paneque started with a mag15 sim ( ?), a totally independent sim to corss check g4
DP: it is a fortran code used in may other places (CDF), honestly do not know which sim is better, a feature of this code is that all physics is in there, so user is not allowed to play with physics processes. idea is to make a very simple geometry and repeat same experiment with G4
LL: certainly a good cross check, but a dangerous direction to go, we will not change our simulation in any way now, and we are confident that G4 is under control from what we have tested so far
FL: good for checking physical processes, we did it in the beginning between G4 and egse4. it is hard to compare two different MC with different geometries
BL: agree, does not make sense to include all geometry details, we should just look at transverse and longitudinal profile and see if we have some differences. comparison done so far between g3 and g4 was useful, but they are basically the same, for the moment we just compare different MC, so apples and apples
Discussion on status and plans
BL: eventually we will only need a single factor, and this is more simple, so we should start from that
AC: correction for recon goes into digi, one way is to correct calibration constant by a constant factor
PB: cal recon uses energy layers info in different ways, so changing energy by 10% in sim is not enough.
EB: so we should base our new sim based on what we learn from data.
BL: very first step to do is modify MC the best we can, like applying single adhoc production, and reevaluate agreement with data and evaluate systematics, and only then involve bill et al
EB: if you just put random changes in sim you can cause big problems in our algs which are not there, so you might produce non-existing effects. we should stick to what you get from data and make MC as close as possible to it. you cannot do it forever I agree, we have to converge and launch the instrument
BL: these would not be random changes, we would start with single constants and evaluate residual discrepancies with controlled systematics. all with minimal change in the code. there are enough constant in the xml file to do it w/o changing the code.
EB: this is ok for the cal, but there is also the TKR issue
LSR: if you change the CAL calib constant the enregy you measure will be different, pretty obvious. if you change the hits in the TKR, you might see a small change in the PSF (maybe). the main change are those affecting the background rejection variables though, if we make changes in the sim we need to make sure we do not introduce strange effects
LSR: this is more assessing systematics, not fixing those
JB: leon, any idea of how we can introduce the extra hits?
LSR: not really a model in mind
LSR: tracy could not get in, he says that all BT sim ave been done with G4v3r8.... which is the very same G4 used by GR and there is only 1 set of linux libraries, so we have that problem coming from the bug he found. it seems to me that once this is fixed it is probably important to run a representative set of hadronic runs (and also EM) to check
JB: we should check this with Michael
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