Unedited notes, corrections and additions are welcome, Luca (LL)
News
LPM effect
LSR: LPM effect exists and we should see it, turning it off should not be the solution.
thin target effect, again largest for high Z material, also suppresses brem, we should not consider this solved until we get a coorect implementation
JB: you are right, I never said the problem is solved, we just know the current implementaiton is not correct and the G4 developers advised us to do so. we already saw we need some LPM effect, starting from 100GeV or so. will have to work with our data and the g4 team to implement this correctly
BG: turning LPM off is like having an upper limit, right?
JB: yes
BG: whatever we get when we switch it on will be less than what we have with LPM off?
JB: somerhing that philippe brought up some times, is the connection between hits agreement and extra material
Temperature correction for CAL pedestal
see the posted summary from Sasha
BG: any chance to get pedestal correction for some proton runs where I saw drift of MIP peak?
AC: you can apply to any run and the pedestal will be correct,except that I do not correct for rate effect
BG: took care of that, picked the low rate runs and cut on GemDeltaEvtTime
PB: the idea is to get a stable BT release, and then reprocess all the data
LL: Johan and Francesco will take care of the reprocessing?
JB: yes, we can do it on the pipeline or locally
LL: either way, we should advertise the reprocessed data to have more eyes on those
AC: I just noticed some strange things related to T measurement, namely time; it looks like time in start-time column in run db not always match time in logbook. a 9 hours shift appear and disappeared afterwards, around august 9
JB: what happened I think is that we changed the time of the BTserver, where the HKP lookgbook was residing. we changed it from SLAC time to european time at users request.
AC: another thing we noticed, there was some strange change in T, like an abrupt step up and down of about 1 deg, definitely not real cooling and heating, happened in 5 minutes, so it is too fast, it seems to be correlated with power up and down. it seems that even if CU is powered down, temperature is still measured
CS: T monitor are on the cables, and can be readout with FE off
AC: but it changes immediately, it cannot be heating from the FE
CS: yes, we observed that during TVAC tests, there is some sort of xtalk that changes the T value when switching on or off the FE
PB: what are the 4 columns in the T file?
AC: 4 sensors
PB: 5 sep gives no data for two towers
AC: looks like tower 2 or 3 gave no T for that day
JB: for some time we ran with some special config with just 1 TEM on, I think that was a CPT
AC: anyway it seems that for all periods when we took data we have T available
Data reprocessing with EM hypothesis
2: black is behind red
3: the only differences are in the Kalman filter related variables
4: some more plots
5: conclusions. we should use the same hypothesis in data and MC
PB: we should use the EM hypothesis for gamma and electron runs, not for hadron runs
CS: right, i think we have the same discrepancy (MC flag and data flag) for the electron runs, did not check the hadron runs
PB: we need to have the same hypothesis for MC and data
JB: we always used MIP for data and EM for MC
LSR: just to remind people of what this is, obviously for MIP hypothesis there is a dE/dx calculation mainly coming in for the kalman energy estimate; for the EM hypothesis, we assume the energy deposition goes down along the layers by an exponential in rad. lengths. So for the same track, the kalman energy will be higher for the e-radloss hypothesis. This affects the fit itself which uses this info. to partition the energy between the vertex tracks. so you should see some 2nd order effect from that