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