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