Beam Test Meeting notes - 17/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), Philippe
Bruel (PB), Leon S Rochester (LSR), Claudia Monte (CM), Hiro Tajima (HT), Fransco Longo (FL), Benoit Lott (BL), Alex Moiseev,
Yvonne, Sasha Chechtman (SC), David Paneque, Ping Wang, Monica Brigida (MB), Bijan Berenji, PierGiorgio Fusco, Gary Godfrey, Elena, David Paneque
News
CU shipment to SLAC authorized, will be at SLAC for ISOC workshop and Luca and Carmelo will test it. Then it will become a testbed in the ISOC
Discussion on reprocessing data
bug in cal xtal response, now fixed and reprocess in progress for PS.
problem with oracle db that stopped for a few hours today, now fixed and reprocessing going on. almost 1/3 (158 runs) PS data reprocessed now. i did a mistake choosing a wrong version of svac tuple, fixed it and restarted reprocess. next is SPS data.
This is the first massive reprocess since 3 months!
reprocess for GSI data next task, including new features from GR (see below).
I think it is importante to schedule a MC reprocess. We have a new root infrastructure for easier file merging (merit and svac tuples), changes to G4generator that allow easier rotations, a bug fix in bttuple, new beamtest06 tag (small issues on SPS geometry, air between cerenkov and gas pressure).
Technically Will need work as a single MC file require a task so we must regenerate lots of tasks.
i suggest to finish data reprocess, then recreate task names for all MC runs (and more) with newest BT release (see connection with GR).
LSR: simple digi has a first attempt at a charge spreading model, should go in latest tag of GR
PB: differences for calxtal response, BT is ahead of GR, so must be sure we keep this last and not the last in GR
FL: correct
PB: anyway energy will not be different after data reprocess because xtalk correction is limited to neighbouring xtal
JB: do we need to update JO as we did last time for first massive production?
FL: must do that, your help is welcome
FL: also important change is to include TKR calibrations (dead, hot strips)
PB: also possibility of tilting CU along Y direction (connected to changes to G4generator)
LSR: never really understood why calibration files could not be loaded
FL: JO technicalities
LL: we will have also channel gain variations if we make sure calbrations are loaded?
FL: yes. I suggest to test with BT aligned with GRv9 and then add new G4 generator
LL: sync BT and GR - leon do you want to add more?
LSR: we could update to GR v9r25 and would work for the digi changes. G4Generator is another issue. There are some changes to the MC event data that went in before the tilt fix, so we may have to update Event, RootIO, etc. too.
TKR digi implementation
LSR: charge sharing in place. Also fixed problem that effectively applied simple digi thresholds after Bari digit, therefore overwriting Bari
LL: can we get two digi algos in new MC?
LSR: no, must set right JO to choose one of the two
LL: should have a list of representative runs and make sure we run MC with the two implementations for these
MB: Level1 digi is ready, trigger simulation is in progress. Code already running in BT release, ready to provide JO prescriptions to select bari digit
Hadronic cascades
JB: first quick update on g4 standalone simulation shown last week: found that even at 1GeV w/o tracker the shift is still there, so we don't trust this simulation anymore. Also the code eveolved to include strips readout in tracker (thanks franz), and carmelo is working on that and will soon show results
JB: now on hadronic cascades: more systematic analysis, see page 2 for all physics list available. So far tested std glast model. QGS are high energy models (>20GeV), but two of them not accessible from BT.
as usual many MC if we combine energies and physics lists, not to talk about angles.
in this analysis i did not want to cut on data but rather work on beam spot to reproduce data, only cut is require > 8 logs in cal (big cut though); will have to apply cut on delta event time too
pi 5 gev agreement very good both for CAL and TKR variables (surprisingly good for TKR hits)
from slide 5 on same set of plot for protons at 6, 10 , 20 , 100 GeV
conclusions: having a trigger implementation at SPS would help. generally ok below 20GeV. what will happen with data reprocess? PB said it should not change a lot
comment from PB (sorry i lost it)
FL: we should define which physics list we should test, in view of the next mass MC production and the information we should give to collaboration. G4 people advertise QGSP for high energy, maybe we could try that.
JB: should use bertini at low energy, early to say which is best at high energy.
FL: yes but which should we run for mass simulation then? and where did you run yous simulations?
JB: locally, so very little statistics. agree we should define models to test.
FL: this week there will be a g4 review at cern, i will ask them about suggestions
LL: francesco and JB will make a list of desired physics list to test for new MC production run
BL: definitely room for improvement at 20 gev, not very good agreement. events in MC with very few hit logs, maybe related to beam spot
JB: yes noticed that especially in tkr plots. track1 data falls into a crack and have <36 hits
PB: you should look at caltransrms vs cal energy raw in a 2D plot comparison
FL: should discuss these results with people looking at CT variables
LL: can we say that tkr1hits are well reproduced? also for e? the only place where there is discrepancy is 20GeV but you said we hit a tkr crack in MC
JB: yes, tkr1numhits is in fact a collection of clusters associated to 1st track, and there is agreement
LSR: i cannot really see the slides, sorry for that,problem with acrobat reader, but in general for high energy we must make sure buffer size are well reproduced both in MC and data
JB: not sure i understand, but even at 100GeV we do not have so many hits to saturate buffers with hadrons
LSR: so maybe not a problem, but we should make sure we use the same buffer size used for data
JB: talking about FIFO settings?
LSR: yes
BL: nb of fits Tkr2NumHits is very different between data and MC as far as saturation is concernced. data sharply saturates at value different from MC - bug or feature? also for p 6 geV slide 14. LSR is right we should check that
LSR: for the 20-GeV protons, it looks like both track 1 and track 2 are shorter in MC (gap perhaps?). For 5GeV pions, and 6 and 10Gev protons, there are some events with 2 long tracks in the data, but not in the MC. Could this be real 2nd tracks from the beam?
LL: second meeting only lasting 1 hour, good but even better if we go back to the 2 hour excitment. talk to you next week