Hi,
We'll have our backgrounds/simulation meeting this Saturday, Dec. 11, from 0900-1200 in the Racetrack, 7th floor crosshover in WH. Video is available, and details will be sent soon. Thanks to Jon Link for arranging the room.
My hope is that we can make some concrete decisions at this meeting, and I hope to use this e-mail to try and develop the agenda. Towards that end, I'll offer up a list (not complete) of questions and some requests and my opinions. These are for the purposes of stimulating some pre-meeting discussion and generating a more useful agenda, which I'll try to get out Thursday.
Reminder, opinions, bad ones and the occasional good ones, are mine, and are for the purpose of trying to focus the discussion.
1. Question 1: how should we develop our parametric simulation (hereafter Fsim) and a full simulation (herafter G4).
Request: 15' Status of ReactorFsim -- Matt W.
15' A Geant4 neutrino detector description-- Dmitri Onoprienko (KSU).
15' A "Generic" simulation derived from KAMLAND -- Glenn Horton-Smith (KSU).
My opinions: 1. ReactorFsim augmented by parametric flux packages and a parametric veto system simulation package should be the primary tool for the experiment at least through the R&D proposal decision stage.
2. The Spokes should identify a group to lead the development of the veto simulation.
3. The Spokes should identify a group to lead the development of a full simulation based on Geant4..
4. Individuals from any institution can contribute to any simulations via cvs.
5. The experiment should on the long term maintain both simulations.
2. Question 2: Unavoidable issues in theology.
Requests: This discussion CANNOT last more than 30 minutes.
15' cvs tools-- Matt W.
My opinions: 1. The full simulation should be built on Geant4. Long term this package will be the best supported and best tested.
2. No new Fortran. Legacy packages are OK if sufficiently justified.
3. New coding should be done in C++.
4. cvs should be used for any software that produces a Braidwood result that is to be shown to the outside world.
5. Matt's documentation tools must be used.
7. One institution (UC?) should serve as the central cvs repositoty for ALL software that produces a Braidwood result that is to be shown to the outside world.
6. That's enough rules.
3. Question 3: What does ReactorFsim need?
Requests: 15' Thoughts, UT progress-- Josh K.
15' Thoughts, KSU progress-- Tim B.
.... -- anybody else?
My opinions: 1. The output of ReactorFsim should be an array of PMT objects. Each PMT object should save a time history of the simulated event. The time history needs to be defined. All trigger/electronics/reco functions then can be implemented on this data structure.
2. Our needs are sufficiently simple that we should NOT implement G4 class libraries. This will keep the Fsim independent of Geant, and I would argue, easier to keep up (no need to keep track of G4 updates).
3. We need several categories of functions. These of course duplicate G4, but see 2.
A. Geometry
--keep spherical approx. as much as possible. "Post-process" non-spherical effects.
-- add finite thickness acryllic.
-- PMT geometry?
B. Physics
--flux. These should be functions that could "feed" either the nu det. or veto. Some (PMT rad) may need to be customized for one or the other.
a. nubar (done)
b. muons (done)
c. neutrons
d. gammas (done? but possibly needs explanation/discussion)
--cross sections
a. nubar (done)
b. mu+N
c. n+N (done for E<20 MeV or so)
d. e+ annihilation (done, but no positronium)
e. gamma (Compton, done; P.E. ?)
f. charged particle soft --> treat via MCS (below)
g. inelastic hadron (use Geant libraries?)
h. Li9, etc should be "forced", not down mu by mu.
-- decay
a. muon (done?)
b. Li9,He8 (done)
c. K40, Tl , other PMT (done)
d. U,Th chains
C. Track propagation
a. neutrons (done for E<~20 MeV)
b. gammas (done, only Compton)
c. e+/e- dE/dX (done at one point)
d. muon, proton dE/dX (Landau only should be OK)
e. MCS
f. Boundary checking (no finite thickness acryllic yet).
g. inelastic
D. Response
a. light propagation (no need to track single photons?)
b. Birk effects (easy to implement, but correct?)
c. PMT response (now includes only solid angle, QE, Poisson effects on npe)
d. PMT digitization
E. Reco
a. single vertex RECO (done in two simple implementations)
b. double vertex RECO (fun project to try)
c. e+ vs e- RECO (fun project to try)
d. line segment (mu) RECO (fund project to try)
F. Analysis
a. PAW (exists, clunky but easy, ReactorNtuple should be viewed as user function)
b. ROOT (encourage development)
4. Question 4: How do we combine the veto simulation with the nu detector simulation in Fsim, G4.
My opinions: 1. The veto simulation should be used stand-alone to produce flux functions for mu and n that can be called from ReactorFsim.
2. Flux functions need to be strongly associated with a particular veto configuartion.
3. A given veto configuration should generate a function that gives muon tracking reolution functions for use in the RECO part of Fsim.
4. At the G4 level, the veto and detector should function as as an integrated package.
TB
Received on Wed Dec 8 10:23:43 2004
This archive was generated by hypermail 2.1.8 : Sat Dec 11 2004 - 03:28:24 CST