Beam Test Meeting notes - 11/4

These are notes taken in realtime from the meeting, please feel free to correct them or add your input

Present:

Luca Latronico (LL), Nico Giglietto (NG), M Nicola Mazziotta (MNM), Johan Bregeon (JB), Tomi Yilinen (TY), Philippe
Bruel (PB), Leon S Rochester (LSR), Claudia Monte (CM), Richard Dubois (RD), Hiro Tajima (HT), Thierry Reposeur (TR),
Yvonne, Francesco Giordano, Sasha Chechtman (SC), David Paneque, Ping Wang, Monica Brigida (MB)

News

LL: Symposum paper ready to submit. will submit tonight

Slides from JB

JB: added beam angle, divergence, EM physics list; no apparent effects from beam size or honeycomb structure vs homogeneous; remarkable effect using penelope physics list, showers starts earlier than std physics list for all Penelope profiles vs std; effect is comparable to extra 0.2X0, suspicious about bugs

Discussion

AC: what is the difference between G4std and std?
JB: only changed std to Penelope
MNM: code is valid up to few GeV - should try a run with both std and penelope
LL: reporting Francesco Longo email (he is ill) EM physics in G4 does not kill a specific physics list out of its validity range, as it does for hadronic physics
JB: working on 1GeV simulation
MNM: looking at max e deposit of 300MeV penelope should be valid
RD: Francesco looked at G4 LE physics

Slides from PB

PB: CAL position meausurement presented last week and giving 1cm offset was due to a bug in software; this was fixed and now position measurment is centered on 0

Discussion

SC: why some plots have ni data point? and what is the parameter d? if it is distance from the center shower it should be bigger in many cases, so there must be some other bug
PB: no data points due to some combination of cuts and asimmetries in data taking; d parameter is actually strange
RD: is there any way for aligning the crystals in recon ala TKR? do we have to take care or is it done?
SC: so far not really done, should do it with heavy ions and not with showers; i suspect intercalibration procedure provides some sort of alignment becasue we check that with muons; first we should make sure pedestal are well measured because position measurement is very sensitive to pedestal at very low energy; probably we should use closest pedestal file for position measurement, or even pedestal event collected simultaneously

Discussion on reprocessing data

we will switch on xtal xtalk in JO; zach sent info on how to do it; will ask franz to generate a e run with Penelope physics list in BTRelease
MNM: should have a status page of reprocesses
PB: pipeline should give that by default, is it not richard?
RD: correct, pipeline web interface does that already, and francesco maintains a page which is mornally updated after the fact
LL: might use beamlist to update people
JB: all runs will be reprocessed soon, you will get all runs soon
PB: reprocess SPS data with SPS pedestal file?
SC: should do that, will check with zach and tell
PB: i thought we would automatically pick up most recent pedestal
SC: we normally specifiy validity for pedestal files in calib DB, and we did it using the same PS pedestal for all runs
JB: not so straightforward as it requires adding single pedestal files to calib DB
LL: at least we know that pedestal did not change so much, i remember sasha's presentation showing that
SC: true, but position measurement at mm scale is very sensitive to pedestal so must update
PB: so let's reprocess with current pedestal and check effect on few runs
SC: i can collect all pedestal an update calib DB
LL: fine, but let's first check pedestal effect on the run that philippe analized so we can evaluate if it is really necessary to update calib DB for each pedestal run

Slides from MB

TKR digi: LL reminds that work is going on between Leon and Bari to deliver new TKR digi algos
MB: presents update of bari digit level1 current bari code not optmized for CPU time, currently can be almost performing as simple for 10 cluster implementation bari code shows slight improvement wrt to simple algorithm

Discussion

LSR: one issue that nicola raised is that ... (lost it sorry) implemented a first version of heavy ion charge spreading, requested for GCRCalib people; implemented the charge injection measurements in the simulation and started checking vs GSI data
HT: channel dispersion are not included in bari simulation and therefore still large discrepancy data-MC (slide 7) and this is the main thing we must include asap, before spending effort in changing other things which give minor effect
LSR: not so sure this is the main effect, but we should talk for sorting this out
HT: threshold effect coming from channel dispersion dominates, can bari MC implement channel dispersion?
MNM: must load calib DB into our MC, need help from Leon or Franz to fix this as it is a general issue; we can use a random fluctuation in our code and check what happens
HT: that is a reasonable way to test effect
LSR: we should be able to load calib DB, we just make sure the JO is correct
MNM: please let us know how to set JO properly and we will see

  • No labels