Meeting 53: August 29, 2007
Unedited notes taken during the meeting, additions/corrections are welcome, LL
Participants: Leon S Rochester (LSR), Luca Latronico (LL), Benoit Lott (BL), Elliott Bloom (EB), Bijan Berenji (BB), Philippe Bruel (PB), Carmelo Sgro (CS), Berrie Giebels (BG), Takaaki Tanaka (TT), Gary Godfrey (GG), Hiro Tajima (HT), Ping Wang, MarioNicola Mazziotta (MNM), Anders, Jan Conrad (JC), Markus Ackermann,
News
BTRelease status
LL: there is a tag now available, michael made it for better tracking of the changes and a more fresh reference, he is still hunting the bug
LSR: our little system test ran on it, 100MeV vertical gammas, some changes wrt to long ago last one (v9r25), just minor changes in the ACD distribution
LL: thanks
Comparison of geometry model with measurements - Leon
LSR: finally got around this last weekend. current gleam geometry established from data I had in 2003 from original spreadsheet. Not only I made a number of compromises and decisions, but several things have changed since then so I made a comparison with measurements that Sandro presented here some time ago.
3: nbs agrees quite well with tower mass measured
4: details of the calculation
5: I used detCheck which produces a breakdown of materials in the geometry model; it outputs 2 versions, 1 is broken down by material type (slide 5) and a second broken down by element name (6).
I stuck numbers from these tables to calculate what gleam thinks we have in the model
7: very general comparison between gleam and sandro's numbers
active mass is the mass seen by a particle going down, passive mass is closeout mass
EB: does active mass include W?
LSR: yes it does
LL: correct, just want to add that active mass is defined as anything inside the silicon area, and does not take into account holes between ladders
LL: actually Sandro scaled the mass for a solid surface and a surface with such holes
EB: what is measured using muons?
LSR: I shot vertical muons through the TKR and in the tuple I get a number that is amount of material traversed by the particle (firgit the variable name LL); in any case you see a minor difference
EB: passive is crossing towers right? so it has an effect for inclined tracks
LSR: exactly, but that is for most particles so it can matters, although as you will see the difference is small
8: comparison of active masses; stuff is basically the payload (glue, bias circuit...) the main differences shows in the stuff, i seem to be missing 40gr/tray
9: passive mass: generally closeout are heavier in reality, while walls are heavier in the model, which probably balances the missing cables in the model
10: tray masses: minor difference with sandro (140gr), but by and large the bottom tray is much heavier, next is the top tray. I guess some other fixtures (corner flexures, brackets, cable retainer on the top) were included in the trays
11: bottom line is that all discrepancies are understood and easy to correct; by easy I mean that somebody with time and patience can do it, it is not rocket science but a far amount of work
LL: thanks leon, this agreement was somehow expected, but it is good to see it done thouroughlly; I will ask the same to Sasha and CAL people
New LowEnergy simulations - Carmelo
see slides for clear explanation LL
10: McPositionHit shows different behaviour for TKR and ACD, McIntegratingHits shows no difference for the CAL energy deposit. this is more for the experts to check, francesco is looking at this as well.
LL: before we start discussing, I would like to add that we had LE sims in the past which showed no difference, so we are investigating on that. the difference with those simulations is the more complicated environment and the geometry (cal with non-empty gaps)
LSR: i think there is no threshold in standalone sim
CS: anyway the energy deposition is bigger (alide10) and this is strange
EB: slide 10, lower right, it seems that if you divide by two the red plot it overlaps with the black, could it be some calibration issue?
CS: yes, we are thinking about something like that, but it is not clear to understand if it is a factor 2 or what
MNM: there seem to be less hits but more energetic wrt standard ones
CS: these are not hits, these are single energy depositions, do not know how to relate this to tkr hits
LL: we should anyway normalise the plots to compare (audio problems could not hear if plots are already normalized LL)
BL: to what extent can we expect differences wrt std phyisics? LE does not refer to incoming energy, but to the range of particles and how we follow them right? so we should not see this difference
LL: that is what I understand from LE, but i think those are a completely different set of cross-sections. it remains strange to understand how you can get up to 10-15 GeV more in the CAL, as is the case for high energy incoming electrons, by following very low energy particles to shorter ranges
BL: agree with that
LL: maybe this is a good thing to show to g4 people, if the only change we have is in the selection of physics list we have a clear example to show them
BG: why not checking on a simpler geometry like a single CsI bar? why would you show them this is standalone sims with LE and w/o match?
LL: good point, that is why we are redoing the LE sim in standalone g4, in any case they might help and show us what we do wrong in the way we handle different physics lists
CS: g4 standalone sim is part of BTRelease, so you can play yourself
BL: what do you expect from the last line test with QGSP_BERT? that is a hadronic model, you should see no difference
CS: we do not expect changes, I agree. Francesco wanted to do that. Another comment is that we sure have a bug in the ToT and need to fix it
CS: just made the plot that EB suggested (get it from the shared files tab). actually by dividing the LE energy deposit by two the plots overlap well
EB: david has preliminary results in CsI cal comparing g4 and egs5 and got very similar results, but what we may be seeing here is some bug in geometry
LL: we may have something similar to what we had for the TKR alignment. I invite all to check those files anyway and help discovering is and what bug we have
Participants: Luca Latronico (LL), Hiro Tajima (HT), Johan Bregeon, Nicola Mazziotta, Taka Tanaka, Alexandre Chekhtman (AC), David Paneque (DP), Elliott Bloom (EB), Francesco Longo (FL), Ping Wang, Markus Ackermann, Gary Godfrey, Eduardo do Couto e Silva, Bijan Berenji
Unedited notes taken during the meeting, corrections/additions are welcome LL
News
LL: Added a link to a page with list of good runs. they were generated with the specified conditions after beam spot tuning. This is priority list for runs that will be generates as soon as the new BTRelease is ready; this is also an invitation for people to flash out relevant runs - please add them to this page
JB: just want to add that not all runs have a configuration ready yet, e.g. tagged photons runs require beam spot tunig
MNM: about the cerenkov pressure at SPS - 3atm seems to much for 10GeV e, can you confirm this value?
JB: I had hard time finding this info, pretty sure this is good, i can check again in the logbook
MNM: i remember cerenkov were empty during e runs as they should
JB: well, this is a particular run at 10 gev, and at that time we were playing with the cerenkov to get them right, i will double check, we should have done it with empty cerenkov I agree, but that is the pressure value i found in the logbook, it may be that we have not done it right
LL: maybe we can do an independent cross-check
g4-egs5 comparison - David
DP: made it in a hurry before the collaboration meeting, study will get more complex with time. geometry is simple, 30 X0 cal segmented in both directions - no gaps yet.
2: the g4 model that benoit provided and was used for comparison. you can see transverse and longitudinal profiles
3: results from egs5, transverse RMS and longitudinal are similar, rather good agreement as you can see
4: overlay of longitudinal profiles (it is egs5 and not egs4 as in the title, sorry) - there is a small shift towards higher values for egs5, we will investigate. Did not overlay transverse profiles as we realized we were shooting in slightly different place.
Following slides are the same for 10 GeV e - agreement is again good, probably better than for 100GeV
9: plan for further developments
AC: about the todolist, the statement that we do not need 3D is not completely coirrect, as we do not have axial summetry for non-zero angle
DP: correct, we did not think about it, thanks for the comment
LSR: probably get away from that by putting the beam in at an angle but orthogonal directions, you can measure essentialy separate projections
DP: guess it is another possibility. maybe not too hard to implement 3D, maybe an issue for running time, we wiil see
BTRelease udpate - Johan/Michael/Franz
JB: report of what changed and what remains to be fixed before the new release.
2: initial goal was to synch with GR and update JO files, expected lots of debug and had to do it!
3: TKR changes (handle Bari digit, alignment history in the MC) and ACD changes from Luis
4: G4 hadronic physics and beamtest06 updates. today francesco compiled LE version of G4HadronSim and it works today. now we can use it again, we had lost it at some point,cannot say exactly when.
5: what we need to do now - must solve couple of bugs (LE physics bug fixed today); memory leak still to find, segfalut from acdgeometry.
LL: how do we keep the synchronization between GR and BT? we started from moving BT at the same level as GR, but then there are things we find in the BT that are not yet in GR, what is the strategy for maintaining the synchronization?
JB: to be more explicit, sync means core packages, i.e. things we do not see or changes so frequently
LSR: the fix for the 2 alignment codes is already in GR, did not feel the need for a permission to include that as the default is still the simple alg. About the fixes for G4, are the LE fixes for hadronic physics or more general?
JB: they are more general, also for EM phyisics - we had a bug as we were calling LE physics routine for e+ which do not have LE physics as they annihilate at LE. we fixed this today
DP: this may be a reason why we have more hits in the data, maybe vecause e+ were not followed?
JB: this is only related to LE physics, which we had not used for some time
FL: the bug is in the way we handle the LE physics list, it has always been there, and it is not related to e+ bug
DP: what is the benefit you expect from this? is it worth?
FL: when you go to low range cuts, you go into a wrong situation ... in a few words, the EM MC is a mixture of hard and continuos processes, in particular MCS is done in continuos way, a soft interaction closely followed by a hard interaction for large angle scattering ...... (lost this part)
LL: the way I see this is a systematic way of redoing LE and low cutoff simulations in the context of the new BTRelease, good that we found this bug and are taking care of that.
TKR range cutoff studies - Johan
JB: this is very preliminary. recent brainstorming about TKR hits, one idea about low range cuts, one about w fluorescence, one about tkr geometry (see leon)
3: 1 vs 100um cuts, really no change
LSR: what is the beam energy here?
JB: 20geV e, run 2082
LSR: are you sure the cut is implemented? does the job run 10-20 times slower?
JB: good point, I was surprised that the distributions are exactly the same, rechecked the run-log and verified that the cutoff was actually different
4: another option is to run the CUTower stadlone sim, where I also have possibility of runnig different cuts. here indeed the job is slow, there is no optimization in CUTower
LL: we shouold have no surprise given previous results shown by Francedsco that had no change going down to a 10um range cutoff right?
JB: we should make this a systematic test and use LE physics as well, otherwise g4 does not follow to low range cutoffs
FL: correct. in fact g4 colaboration is trying to make the process independent of the cuts. My previoius tests were done with g4 standalone and there LE physics is properly dealt with, so those are reliable and showed no change indeed
New Geometry for silicon/bias glue layer - Leon
LSR: just changed a few lines in the xml file that joanne put together, just started last night after 6 and made it, so it is a good model!
4 and 5 show the change i made
6 and 7 are a picture of a track crossing a silicon, there seems to be no change for tracking, we should check what happens with the simulation. will take some more time to figure that out
Some considerations for implementing a "real" geometry - Leon
LSR: sent around some notes and thought I should talk about these ideas in this meeting. The idea is that we should find a way of putting displacements in gleam from beginning to get simulation right
3: actual situation as it is dealt by michael in current alignemnt
4: alternative thinking about tray displaced as the average of the 2 planes displacements
5: trays are at nominal position, faces of silicon are misplaced by the known 150 um in average
7: arbitrarily plotted as positive numbers
8: combining vertical displacements and rotation-induced displacements we can see that some faces would hit ideal tray position, the alignment code must realize there is a physical tray
9: two possible ways to handle this, align close planes or model thinner kapton layers and leave trays core in nominal positions (i think this is the right solution)
FL: as a general comment, maybe related to the way we handle geometry in xml - how could it be that with the real alignment constant we hit the trays?
LSR: silicon planes are maybe not perfect planes, they might bow at the centre, and similar effectds come in
LL: so leon if i understand correctly you are saying that si planes are shifted by 150um wrt the model, and you propose to move them and make the facesheet/glue/kapton layer smaller to leave room for displacements and avoid si planes to hit tray cores
LSR: right, there are two issues, one issue is that we have to move the si planes 150 um apart wrt current model, basically by moving the si layers, and this is easy.
the second issue is that if we try real geometry we will start rotating these planes and in a few cases we will end up with the silicon hitting the tray, and there I think we should probably use a thinner denser layer to allow more space for silicon planes to move and not hit tray cores
FL: do we plan similar geometry checks for the CAL
LL: the last I heard from Sasha on this is that they think the model is matching what they have from construction data. it is true that alignment with the cal is tricky and not precise as with the TKR. I do not know if and how they use tracks extrapolation to measure alignment of the logs
FL: i meant a thourough check of the materials used, more than the alignment itself
LL:ok, will ask sasha to report on that, but I remember him saying that there is a good model in the simulation
Meeting 48: July 4, 2007
Participants: Luca Latronico (LL), Philippe Bruel (PB), Berrie Giebels (BG), Leon S Rochester (LSR), Benoit Lott (BL), David Paneque (DP), Johan Bregeon (JB), Nicola Mazziotta (MNM), Claudia Monte, Tyrel Jonhson (TJ), Tomi Ylinen, Taka Tanaka, Jan Conrad, Monica Brigida
News
JB: working on synch BT with GR, currently experiencing some sug fault to fix with Michael, also working with Monica in Bari to check Bari digit implementation
CAL energy checks
PB: 1st plot is the one sent beforethrough the BT mailing list. The idea is to check the stability of CAL response with calibration runs. Looked at raw total energy and energy in layers, using as a reference 2024 (on-axis 100GeV e), and looking at energy and dividing by reference energy.
There are 4 scans, red arrows are twr2 scans, blue are twr3 scans, first 2 are Y scans, second 2 are X scan.
Applied my std cuts, in particular cuts that remove electrons too close to xtal boundaries. Cut is 0.4 for first plots, i.e. I keep only e that are within +-40% of 1 log. Really surprised by results, in particular in layer0 and 1, where a big difference can be seen for X and Y scans. First and last points of the scan are expected to be lower since you are actually shooting close to the xtal boundary, the rest of the scan should be stable. Johan told me we might see a problem with the beam position here. I tried making a harder cut, and there is an effect if you look at the other plots you see that. I am quite surprised by the sensitivity to this interlog cut, maybe not so obvious to conclude now.
The last plot with 0.25 cut still has instabilities, e.g. layer6. I need to check that the interlog cut is enough.
BL: is this the mean energy? the change is about 15% between the plots with 0.4 cut and 0.25 cut, which would mean that the energy is lost in cracks or something, surprising
PB: at high energies, when you are close to the interlog boundary, there is a strong effect, I am sending some slides
JB: in the first layers the shower has not developed yet, so we are bound to see a larger effect
PB: looking at the slides I just check sent, slide2, you see the strong effect, interlog cut at 0.4 means between 0.1 and 0.9 on slide2, cut at 0.3 means between 0.2 and 0.8...
LSR: lost the comment
PB: what is odd is when you look at the plots with 0.4 cut, it is higher for layer0 for this scan
Most probable energy - Nicola
MNM: today I would like to show some plots on the most probable energy. I already showed the CAL profile fitting on the 10 jan VRVS.
This shows the ratio of the various energy variables wrt to beam energy, it shows a 10% excess in the SPS runs, same for all incoming angles, could you comment on that?
PB: this is due to the energy raw excess; since all algorithms are based on the CalEnergyRaw, an excess there reflects into an excess in the corrected variables. I warn people that the only algorithm that is always defined in the whole energy range is the one giving EvtEnergyCorr, the other variables are not always defined in the full energy range
MNM: does this not mean that we have an overestimation of the data energy? what does it have to do with MC?
PB: yes, but it is due to the difference in CalEnergyRaw, the algorithm corrects for the missing energy, based on MC
LL: cannot really answer your question Nicola, we do not know if we have an excess in the data or an underestimation in the MC, but we have evidence that the energy deposit is what is expected from the longitudinal shower profile and the material upstream the CU
PB: not that obvious, the fact that we do not have a continuos cal but a cal with gaps says it is not obvious. all the work done with shower profile fitting was done with a continuous cal. all we know is that the algorithms are optimized on MC, so if we have to change the MC we have to redo the algorithm optimization, so I hope we can change the data (with calibrations or so)
discussion on error bars in Nicola's plots
Summary plots
LL: compiled a list of plots and updates that we should collect to summarize our results for us, the collaboration and the G4 developers to request their collaboration and help. Please review the list, add suggestions and start attaching the plots
LSR: might be useful for muons from LAT CR tests. For cluster size, especially for gammas and e, would be useful for separate 1st track from remaining tracks, as so called remaining tracks are kind of random collections of hits, so more meaningful for the 1st tracks
MNM: can we use svac or should we use recon files?
LSR: can use root files
MNM: done this work using the recon files, so need lots of space to store recon files
LSR: have similar problem, finally broken down and now submit jobs to SLAC farm, impossible to do this on my laptop
MNM: could you do this work and check if we can use just the SVAC tuple?
LSR: not sure I can do it in a short time frame
MNM: which SVAC version should we use? we know of a problem in the last data sample
JB: looked at total nb of hits, w/o cuts it is the same, there were many changes in the CalRecon, and this changes the way we identify photons
LL:yes, but if the changes in binning the events energy are so big (btw it is a systematic effect if you look at the plot) then we should see it much better in a CAL related plots, some energy only plot, like correlation of the CU energy and tagger energy for tagged gamma runs
LSR: plot of the energy distribution might be enough? we should see different shape in those distributions
LL: we will see if the differences disappear with the new BTRelease, and also check some energy plots
PB: I have almost all results for the correction factors for the CAL, will show that soon. there is no clear trend so not sure what to conclude. For the profile fit I am not sure we can gain something given all was done with solid models
BL: best would be to directly compare egse4 and geant to know if shower profile is correct. David will do something on this.
LL: anything on MIP discrepancies for CAL too? Berrie had something
BG: we have it for pions too
BL: this effect is a feature, been around for years, the width of the energy distribution is larger than MC
BG: at least at cern we had a well defined MIP beam,
BL: we saw the effect at GSI too, it is already published in our paper. the effect is in the width of the peak, the actual position is fixed by construction in the calibration procedure
LSR: one thing on my list was some kind of backsplash in the TKR, not a 1st order effect, but maybe a 2nd order effect on reconstruction efficiency showing in some special events with saturated buffers or so
TJ: happy to work in that if you give me details
LSR: will do
Comparison with Mars15
DP: compared g4 and mars15 energy deposit for 30 rad length solid cal, 100GeV incoming electron; big differences in the total energy and energy peak. in general g4 gives good resuls, mars15 seems bad. I contacted the mars15 author and told him, he revised things and found a problem in LE electrons, so I will try with EGS (help from Hiro on installation)
PB: I wish to remind that we have to prepare a summar talk for the collaboration meeting
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
Beam Test LAT NewsLetter Report - Issue 4 - submitted 31 may
Luca Latronico
May 31 2007
The Calibration Unit worldwide tour was successfully concluded in the beginning of April, when the module was sent to SLAC and handed off to ISOC-SO that will turn it into a test bed to for studying flight hardware response to flight software.
This was the last step of a successfull series of CU operations carried on by the beam test team since its first integration just about one year ago .
We are happy to deliver such a valuable instrument to the ISOC, and completion of data analysis is now our only target.
On this ground, three main activites were pursued during the last month:
- re-evaluation of data-MC discrepancies after the last data reprocess and updates to the simulation
- completion of the standalone single-tower simulation and comparison with our standard Gleam MC
- systematic exploration of available hadronic physics lists
The most recent changes to our simulation/reconstruction package (BTRelease) include the adjacent crystal cross-talk correction for the calorimeter energy measurement, two alternative Tracker digitization algorithms with description of charge sharing and large signal induced cross-talks, and a correct use of the tracker calibration database.
These last improvements did not significantly improve the data/MC agreement in the CAL energy and in the number of tracker hits, but provided a very accurate description of the measured ToT distribution.
The standalone Geant4 simulation was completed with a realistic tracker tray honeycomb description, as opposed to a density-averaged homogeneuous material. No effect was observed in the total number of hits and in the EM shower development, which is also very similar to the one produced by Gleam. Our conclusions are that Gleam and a standalone Geant4 simulation generate similar EM shower profiles, and a more realistic tray description does not solve either the CAL energy or TKR hits discrepancy.
A more complete survey of the available hadronic physics list in Geant4 was performed, and the currently best results are obtained with the Bertini model up tp 10GeV, and the QGSP libraries above 20GeV. Mor models are being studied now
BeamTest Pipeline Code
The BeamtestRelease version v4r0909p9 was installed on Prod Pipeline for processing last PS runs. It contains the right ancillary detectors reconstruction for lowEnergy runs and a major bug fix for G4 stuck. Main changes with respect to the last CCB action that affect the processing are:
G4Propagator: v2r2p2 12-Aug-06 TU Updates to allow exception handling of G4 errors
G4Generator: v5r16p0 16-Aug-06 TU Updates to allow G4Propagator to do exception handling of G4 errors.
AncillaryDataUtil: v1r0p2 22-Aug-2006 NO Added a new Geometry file, valid from run 1642
(F.Longo)
Code Versions
BeamtestRelease (sim/recon): v4r0909p9
Pipeline version:
v1.4.6
Online/svac (task defs, scripts):
pipeline tasks:
online: v2r4p1
svac pipeline code and tasks:
code/tasks v1r030603p8:
pipelineDatasets v0r3
ISOC code and tasks:
v0r5p0
Apps that run in pipeline:
beamtest06: v5r3p5
eLog: v2r3p1
ConfigTables: v3r2p1
TestReport: v0r0p4 (digi & recon reports):
BeamTestTuple: v1r2 (BT tuple) Same as before
BeamTest Pipeline Code
The BeamtestRelease version v4r0909p11 is installed on Prod Pipeline. It's going to be used for reprocessing the PS data. It contains the right ancillary detectors reconstruction also for lowEnergy runs and few bug fixes. Main changes that will affect the processing are:
CalRecon: v6r4p6 6-Sep-06 MWK (for Bruel) correct CU geo in CalValsCorrTool
BeamTestTuple: v1r2p1 change in dimensions of arrays
(F.Longo)
Code Versions
BeamtestRelease (sim/recon): v4r0909p11
System Tests for this version
System Tests results:
First version results.
Fred version:
v0r99
Pipeline version:
v1.4.6
Online/svac (task defs, scripts):
pipeline tasks:
online: v2r4p1
svac pipeline code and tasks:
code/tasks v1r030603p9:
pipelineDatasets v0r3
ISOC code and tasks:
v0r5p0
Apps that run in pipeline:
beamtest06: v5r3p7
eLog: v2r3p1
ConfigTables: v3r2p1
BeamTestReport: v0r0p7 (digi & recon reports):
- Removed Bay 0 from the plots
- Extended CAL energy plot from 400 MeV to 300 GeV and
made the upper limit scale with the energy.
BeamTestTuple: v1r2p1 (BT tuple) Same as before
BeamTest Pipeline Code
The BeamtestRelease version v4r0909p8 is installed on Prod Pipeline. It contains the right ancillary detectors reconstruction. Look also at the desciption provided by Michael here (F.Longo)
Code Versions
BeamtestRelease (sim/recon): v4r0909p8
System Tests for this version
System Tests results:
First version results.
Fred version:
v0r99
Pipeline version:
v1.4.6
Online/svac (task defs, scripts):
pipeline tasks:
online: v2r4p1
svac pipeline code and tasks:
code/tasks v1r030603p7:
pipelineDatasets v0r3
ISOC code and tasks:
v0r5p0
Apps that run in pipeline:
beamtest06: v5r3p3
eLog: v2r3p1
ConfigTables: v3r2p1
TestReport: v3r6p12 (digi & recon reports):
BeamTestTuple: v1r2 (SVAC tuple) Same as before
Code Versions
BeamtestRelease (sim/recon): v1r030603p5
System Tests for this version
System Tests results:
First version.
Fred version:
v0r99
Pipeline version:
v1.4.6
online/svac (task defs, scripts):
pipeline tasks:
online: v2r4p1
svac pipeline code and tasks:
code/tasks v1r030603p5:
pipelineDatasets v0r3
ISOC code and tasks:
v0r5p0
Apps that run in pipeline:
eLog: v2r3p1
ConfigTables: v3r2p1
TestReport: v3r6p12 (digi & recon reports):
EngineeringModelRoot: v3r0 (SVAC tuple) Same as before
Test
Test posting an image into the log. (Doesnt seem to work, you have to add the image as an attachment)
We are testing the shioft log to see if it is useful for data taking. We cna write long messages like this one and also include pictures and snapshots and correct entriues as well
Luca found oyut a mistake and mustyped all over... ha ha ha !
The cover is sitinmg near the tablke