Present in person: Burin Asavapibhop, Will Brooks, Volker Burkert,
Larry Dennis, Latifa Elouadrhiri, Kyungseon Joo, Joe Manak, John
Price, Stepan Stepanyan, Dennis Weygand.
Present via speaker phone: Maurik Holtrop, David Rowntree, Jianguo Zhao.
Agenda (as distributed):
1:20 Initiate speakerphone connections
ITEM 1 1:30 - 1:35 Revise agenda, comments/changes regarding
distributed minutes, other administrative issues - All
ITEM 2 1:35 - 1:45 Status of progress in checking in GSIM/Recsis
changes
to get TBT to work - Burin's work will be summarized by Will
(Burin has a competing meeting)
ITEM 3 1:45 - 2:05 Preliminary criteria for accuracy of GSIM
calculations - Volker Burkert
ITEM 4 2:05 - 2:30 Summary of timing test results - David
Rowntree/Jianguo
Zhao - discussion of where to go next - all
ITEM 5 2:30 - 3:00 Proposal for how to handle x vs. t relationship
in GSIM
and Recsis -Kyungseon Joo
-------------------------------------------------------------------------------
ITEM 1 - REVISE AGENDA, COMMENTS ON MINUTES, ADMINISTRATIVE - All
No changes, no comments.
Note that the clas_gsim mailing list is archived at:
http://www.cebaf.gov/ccc/hypermail_archives/CLAS/CLAS_GSIM/
If you are aware of CPU's we can use for GSIM, let me know! So far we
have partial use of CPU resources from:
- MIT DEC-Alpha farm (ABACUS)
- UVA Linux/Intel farm
- At least one Linux/Intel CPU at OU, possibly more
- FSU Linux/Intel farm (under development)
ITEM 2 - PROGRESS ON TIME-BASED TRACKING ON GSIM DATA - Burin
Asavapibhop
(Burin's work was summarized by Will)
Burin generated elastic scattering events from within GSIM for 2.4 GeV
beam energy, and reconstructed them in Recsis to evaluate the quality
of the time-based tracking. His observations include:
1) The electron momentum reconstructs as too large by 20 MeV out of
1332 MeV (1.5% systematic shift)
2) The electron theta angle reconstructs as too small by 1.2 degrees
at 30 degrees
3) The electron phi angle is shifted by 2 degrees from its generated
value,
but the distribution is flat, as generated.
4) He got 7.6 MeV resolution for proton W peak, consistent with
Volker's estimate of what it should be, based on Bernhard's
multiple scattering calculation
5) Earlier problems (25 MeV resolution) were caused by relative timing
constants (chamber-to-chamber, sector-to-sector) which are stored
in the map and used by Recsis. He set these to 0 in map entry #1.
6) All changes have been checked in to the default GSIM
7) 200 micron DC resolution is what is currently used by GSIM; when
this is set to 0, he sees no change in the width of the proton W
peak. This is consistent with the expectation that the resolution is
dominated by multiple scattering at this energy.
8) Results are compatible with Volker's predictions, but we need to
do a brief systematic study of the resolution, i.e. if we put in
the current resolution function, are the results consistent with
what we see in the data? At 4 GeV, 2.4 GeV, 1.6 GeV? We need to
parameterize the resolution function so that we can add the drift
chamber resolution on top of the intrinsic multiple scattering
effects
given automatically by GSIM.
A curiosity is that the fitted proton mass calculated from the
electron variables is 936.3 instead of 938.3, a 0.2 % error. With
a 1.5% error in the electron momentum and a 4% error in the
electron angle, one might have guessed the mass error would be
larger....this is probably a clue as to where the problem is....
It would also be good if other people would use Burin's file to see
if undesirable features in the data are also seen in the Monte
Carlo. This will permit separation of the effects of geometric
misalignment, the x vs. t function, etc. from bugs in the tracking
code. Now that Burin has gotten this working, we can actually check
our reconstruction code using simulated data...
It remains to be verified that GSIM and Recsis are using the same
geometry. My recollection was that some people worked very hard on
achieving this a couple of years ago. The two codes certainly
obtain their geometry from different locations.
Burin will look further at this problem by looking at the theta
dependence of the systematic errors he sees.
ITEM 3 - PRELIMINARY CRITERIA FOR ACCURACY OF GSIM CALCULATIONS -
Volker Burkert
Volker has begun to define the accuracy requirements for GSIM, so that
we can choose the best operating parameters for long runs. Since
calculating the calorimeter showers is a slow process, he focused on
calorimeter-related quantities. An important issue is electron-pion
separation; in order to make similar cuts on the data and the
simulation, the calorimeter energy resolution has to be preserved. He
thought that since the intrinsic resolution is approximately 9% at 1
GeV, that a systematic uncertainty of 3% would be tolerable. This
would be correctable, for example, by a slightly different sampling
fraction in the simulated data relative to the real data. (We may have
this anyway, because the scintillator thicknesses in GSIM are all at
the ideal value, and in the detector they're all at or below ideal.)
Volker suggested another means of speeding up the simulation, by
decoupling the electron simulation from the hadronic part. An electron
library would be generated (for perhaps 4,000,000 electrons), and then
each interaction would be simulated by starting with the virtual
photon and proceeding to the hadronic final state; then the electron
response could be added in. There was some discussion as to how this
could be done; Stepan Stepanyan and Joe Manak agreed to come up with a
proposal and feasibility study in two weeks.
He estimated the minimum number of ELECTRONS we need to generate
in order to have useful simulations. They are as follows:
1.6 GeV, 40% B-field - 250,000 events
1.6 GeV, 60% B-field - 250,000 events
2.4 GeV, 40% B-field - 600,000 events
2.4 GeV, 60% B-field - 600,000 events
4.0 GeV, 40% B-field - 1,200,000 events
4.0 GeV, 60% B-field - 1,200,000 events
These are based on 6 - 10 Q^2 bins, depending on beam energy, and
on W bins of 20 MeV. He suggested the Q^2 bins might be best
chosen to have varying width, with smaller bins at lower
Q^2. He chose an average of 1000 counts per bin, to have 3% errors on
average; he suggested that smaller errors would be appropriate for the
smaller Q^2 data.
The total above is 4.1 million events. At 1 event per second, this
will take 48 CPU-days. With, e.g., 20 CPU's, it will require only a
couple of cpu days. With a faster code or more CPU's, it will take
even less time... the main time required will be in managing the runs
and in transporting tapes....
We still have to generate of order 400 times this many events for the
hadronic final state...
ITEM 4 - SUMMARY OF TIMING TESTS - David Rowntree, Jianguo Zhao
Using the benchmark CELEG file
(/home/esc/gsim/mc_inputfiles/2.4gev_p_tgt_1/2.4gev_p_tgt_1.evt)
a series of speed tests have been run. Partial conclusions were
presented in the previous meeting's minutes. In the following I
summarize what was said in the meeting, plus a lot of information from
email messages (see the archive).
The largest amount of time is spent in electromagnetic showers - this
is no surprise. Somewhat surprising, however, is that turning off the
geometry in forward and LA calorimeters only speeds the code up by
50%. Since there are no volumes behind these volumes, I think turning
off geometry and secondaries should give the same results.
Larry Dennis commented that when he looked at the code some years ago,
the slowest process was GEANT deciding which volume it was in on its
next step. He said there was a combinatorial effect which made
progress through highly subdivided volumes slow. This observation
nicely ties together several of our observations, e.g. 1) David and I
found gtnext used 20 - 40 % of the cpu time in profile tests, and this
routine finds the distance to the next boundary; 2) David found that
if you turn off the minitorus (actually DC+FOIL+CC+SC+TORU+MINI)
secondaries, cpu time drops by 25%, but if you just turn off the
minitorus geometry, the cpu time drops by 50%; Jianguo found that for
the group 'MINI' 'TORU' 'EC' 'EC1' 'DC' 'FOIL' 'SC' 'CC' if you turn
off secondaries you get a 38% reduction in cpu time, but if you turn
off geometry you get a 96% reduction in cpu time. It's pretty clear
the code is spending a lot of time on bookkeeping.
A counter-example was provided by Jianguo, who found it took 50% more
cpu time if the geometry of the 'OTHE' volume is turned off compared to
turning off secondaries in this volume; however, Maurik explained this
by saying the primary particles passed through 'OTHE' when its
geometry is off, only to shower in the next available volume,
presumably 'MINI'. (Cole also seems to have found that the command
NOSEC MINI TORU FOIL does not work, which may discolor our
interpretation.) Jianguo and Maurik determined that a large fraction
of the CPU time was being spent in the volume called 'OTHE', a volume
of inert materials (factor of 3 in speed if no secondaries in 'OTHE').
A possible solution to the problem of 'too many volumes' was suggested
by Maurik, "There are options in GEANT ( OPTI, and specific routines)
that allow for optimization in the way GEANT goes through the
volumes. If "volume accounting" is a significant part of cpu, this
would be a place where we can look into optimization."
Some numbers from the email messages:
David, 23 March
1 Default - everything on: 9.99s
2 EC1 turned off: 9.24s
3 EC turned off: 7.24s
4 EC+EC1 turned off: 6.49s
5 FOIL turned off: 9.00s
6 MINI torus turned off: 5.05s
7 DC turned off: 8.55s
8 TORUs turned off: 10.22s
9 CC+SC turned off: 7.83s
10 ALL turned off: 0.11s
11 NOSEC EC: 7.72s
12 NOSEC EC1: 9.37s
13 NOSEC DC+FOIL+CC+SC+TORU+MINI: 7.53s
14 NOSEC ALL: 0.98s
Maurik 23 March
2) The geometry definition of the MINI was never cleaned up by Dale (who
implemented it) and was left with a rather high number of named volumes.
He
should have used the GSPOSP feature. Doing this may improve the 'NOSEC'
result. The only way to prove that would be to do it. (Any volunteers ?)
Jianguo, 25 March
1. With all on default 8:30/100 events
(8 minutes and 30 seconds per 100 events)
I used the same files (generated by Will) as David did
2. NOGEOM 'All' 0:04/100 events
3. NOSEC 'ALL' 0:56/100 events
4. NOSEC 'MINI' 'TORU' 'EC' 'EC1' 'DC' 'FOIL' 'SC' 'CC' 5:20/100 events
5. NOGEOM 'MINI' 'TORU' 'EC' 'EC1' 'DC' 'FOIL' 'SC' 'CC' 0:20/100 events
6. NOSEC 'OTHE' 2:50/per 100
events
7. NOGEOM 'OTHE' 4:16/per 100
events
In response to some of this, we decided to run 1000 CELEG events
through GSIM with a range of cuts. Kyungseon Joo and Volker Burkert
volunteered to evaluate the resulting files (with Recsis and CED,
respectively).
ITEM 5 - PROPOSAL FOR X VS. T IN GSIM AND RECSIS - Kyungseon Joo
Kyungseon presented two possible proposals for how to implement x
vs. t in the simulation and in the reconstruction, including how and
where to smear the resolution. The group selected one of the proposals
with a minor modification, which is to create a new bank called the
DOCA bank (Distance of Closest Approach) to output from GSIM.
A web version of his proposal may be found at
http://www.cebaf.gov/~brooksw/gsim/kjoo_x_vs_t_proposal.
The web version is color coded with extra information; a black-and-white
version is:
In GSIM
1.Calculate DOCA
2.DOCA ---> TDRIFT (linear function ~ 50 micron/ns)
3.TDC = TDRIFT + ( TOF + TPR ) (TOF: time of flight, TPR:
propagation time)
4.TDC stored in DC0 bank
5.DOCA stored in (new) DOCA bank
In GSIMKO
1.DOCA = DOCA (DOCA bank) + PAR* g(x) (PAR: 200 micron, g(x):
gaussian
function)
2.DOCA ---> TDRIFT (our choice of function, linear will be default)
3.(TOF + TPR) = TDC (DC0 bank) - DOCA (DOCA bank) * C
4.TDC = TDRIFT + (TOF + TPR)
In RECSIS
1.TDRIFT = TDC - ( TOF + TPR )
2.TDRIFT ---> DOCA (our choice of function)
Dennis Weygand will implement everything in GSIMKO by next
meeting. Kyungseon will implement everything in GSIM by next
meeting. Burin already implemented the RECSIS changes.
The meeting was adjourned about 3:10 pm.
-------------------------------------------------------------------------------
GSIM Focus Group Members and other GSIM contacts:
- Burin Asavapibhop (U. Massachusetts, on-site at JLAB) 757-269-7322
- Will Brooks (JLAB) 757-269-6391 brooksw@cebaf.gov (core group, GSIM
Focus Group primary contact)
- Volker Burkert (JLAB) 757-269-7540 burkert@cebaf.gov
- Bryan Carnahan (Catholic U) 202-319-5317 or -5315 or 202-483-5205
08carnahan@cua.edu
- Larry Dennis (Florida State U) 850-644-1804
larry@fsulcd.physics.fsu.edu
- Steve Dytman (U. Pittsburgh) 412-624-9244 dytman@vms.cis.pitt.edu
- Laurent Farhi (Saclay, on-site at JLAB) 757-269-7680 farhi@cebaf.gov
(core group)
- Rob Feuerbach (Carnegie-Mellon U.) 412-268-2749(CMU#),
757-269-?(JLAB#) feuerbac@ernest.phys.cmu.edu
- Maurik Holtrop (UNH) 603-862-2019 holtrop@cebaf.gov (GSIM
coordination)
- Kyungseon Joo (UVA, on-site at JLAB) 757-269-5307 kjoo@cebaf.gov (core
group)
- Joe Manak (JLAB) 757-269-5829 manak@cebaf.gov
- Si McAleer (Florida State U) phone? mcaleer@cebaf.gov
- Allena Opper (Ohio U) 740-593-1982 opper@akopper.phy.ohiou.edu
- John Price (RPI) 757-269-7038 pricej@cebaf.gov
- David Rowntree (MIT) 617-258-5442 tree@mitlns.mit.edu (core group)
- Cole Smith (UVA) ? cole@apollo.phys.virginia.edu
- Dave Tedeschi (U. South Carolina) 803-777-1132 tedeschi@sc.edu
- Mike Vineyard (U. Richmond) 804-289-8257 mvineyar@richmond.edu (core
group)
- Dennis Weygand (JLAB) 757-269-5926 weygand@cebaf.gov (GSIM
coordination)
- Jianguo Zhao (MIT) 617-258-5438 jzhao@mitlns.mit.edu (core group)