What follows is a proposed agenda. We have deliberately tries not to fill the schedule with talks so that we can concentrate on discussion.
My hope is that we can make some "small decisions" in the meeting to set up some work over the break, and make some concrete recommendations on "large decisions" for the entire collaboration to present in the January meeting.
I hope Jon will be shortly sending out connection information to the Racetrack.
******************************************************************************************
9:00-9:05 Item 0: Brief introduction-- Tim B. 10'
******************************************************************************************
******************************************************************************************
9:05-10:00 Item 1: How should we develop our parametric simulation (hereafter Fsim) and a full simulation (herafter G4)?
******************************************************************************************
Status of ReactorFsim -- Matt W. 15'
Geant4 neutrino detector shell at KSU-- Tim B. 5'
A "Generic" simulation derived from KAMLAND -- Glenn H-S. 15'
Discussions items:
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. The full simulation should integrate the veto and the detector.
4. Individuals from any institution can contribute to any simulations via cvs.
5. The experiment should on the long term maintain both simulations.
**********************************************************************************
10:00-10:30 item 2: A brief discussion of tools and rules
**********************************************************************************
CVS tools -- Matt W. 15'
Discussion items:
1. New coding should be done in C++? No new Fortran?
2. cvs should be used for any software that produces a Braidwood result that is to be shown to the outside world.
3. Matt's documentation tools must be used.
4. 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.
***********************************************************
10:30-11:30: item 3: What does Fsim need?
Thoughts from Josh -- 15'
Thoughts from Tim -- 15'
Discussion items:
1. Should we continue "stand-alone" or should we try to incorporate G4 class libraries.
2. What are the immediate needs? I'll append part of the long list of ingredients from my previous e-mail.
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 (fun project to try)
F. Analysis
a. PAW (exists, clunky but easy, ReactorNtuple should be viewed as user function)
b. ROOT (encourage development)
pend the long list from my previous e-mail:
******************************************************************
Item 4: (11:30-12:00) Integrating the veto with Fsim
******************************************************************
Discussion items:
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 resolution 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.
Received on Fri Dec 10 09:37:40 2004
This archive was generated by hypermail 2.1.8 : Sat Dec 11 2004 - 03:28:24 CST