Present in person: Will Brooks, Laurent Farhi, Franz Klein, John
Price, David Rowntree, Cole Smith.
Present via speaker phone: Larry Dennis, Maurik Holtrop, Allena
Opper.
Agenda (after modification):
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 - 2:00 Proposal for fast, moderate accuracy acceptance
calculations - Larry Dennis
ITEM 3 2:00 - 2:20 Discussion of timing tests - David Rowntree
ITEM 4 2:20 - 2:30 Bug report for GSIM - Cole Smith
ITEM 5 2:30 - 2:40 Thoughts on long-term requirements for acceptance
calculations - Will Brooks
ITEM 6 2:40 - 3:00 Review of project list - prioritize items,
assign names - All
-------------------------------------------------------------------------------
ITEM 1 - REVISE AGENDA, COMMENTS ON MINUTES, ADMINISTRATIVE - All
Minor changes were made to the agenda.
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
- Several fast CPU's at ODU (DEC Alpha + Linux/Intel)
- FSU Linux/Intel farm (under development)
ITEM 2 - PROPOSAL FOR FAST, MODERATE ACCURACY ACCEPTANCE CALCULATIONS
- Larry Dennis
The motivation for this topic: we already have a lot of analyzed
electron scattering data; if we had acceptance calculations, we could
produce a preliminary cross section immediately. So some people have
an interest in very rapid acceptance calculations of moderate
accuracy.
Larry proposed using a new code for these simulations - based on the
existing SDA simulation. This simulation is known to be fast and
reasonably accurate. Larry's proposal is to take the present version
of SDA, remove the analysis part of it, and use the simulation
part. As it becomes useful, the code could be developed and improved
(independent of SDA evolution).
The initial reaction of the group was somewhat negative; there was not
time to
thoroughly discuss the proposal, so this will be continued next week.
The issues as identified in the meeting seem to be:
1) SPEED
Is SDA's simulation significantly faster than GSIM can be made to
be by choosing appropriate operating parameters? If the code is,
e.g. 100 times faster than GSIM, it would probably be worth
doing. If only a factor of 10 is available, we have to discuss it
further. In SDA, Kyungseon reportedly gets 10-20 events per second
for both simulation and analysis, and Franz reportedly gets 100
events per second throwing single particles, using the simulation
only. Kyungseon (after the meeting) agreed to make an estimate for
SDA's speed in simulation mode, using elastic scattering, just to
give us a benchmark which can be compared with GSIM.
2) MANPOWER
One reason to want a fast simulation is to give us early operating
experience which can help to guide development of the slower, more
accurate simulation. Do we gain overall by diverting manpower
toward this project, or does it impede overall progress to divide
our efforts further? Larry said he may be able to supply some
manpower for this project.
3) GEOMETRY
What is the current status of the geometry in SDA, compared to GSIM
and Recsis? How would geometry changes propagate to (either of) the
simulation codes? Perhaps a fast simulation could be based only on
the nominal geometry, ignoring small shifts, but then the code will
have a more limited role.
Cole commented that Kyungseon found a sampling fraction from SDA which
was about 10% higher than what we see in the data or GSIM.
Franz Klein commented that he had just finished setting up a GEANT
calculation (in Japan) and that he had found the three main parameters
which made the code run faster were: turning off part of the
secondaries, not having too many volumes, and optimizing the step
size. (Happily, these are precisely what we have been working on so
far...)
ITEM 3 - DISCUSSION OF TIMING TESTS - David Rowntree, All
The discussion ranged far and wide, so many of the following comments
are disjoint...
David said Jianguo was still working on investigating the OTHE
volumes, which seem to consume most of GSIM's time, and he is working
on getting the latest version of Recsis to work at MIT.
David ran CELEG events through GSIM with a variety of cuts;
specifically he set the general CUTS and the DCCUTS to 0.1, 1, 10, and
100 MeV, with all other cuts at 0.1 MeV. These files are available for
anyone to inspect at: /home/esc/gsim/mc_outputfiles/vary_cuts.
Volker and Kyungseon agreed to look at these files with CED and Recsis,
respectively.
Maurik pointed out that wherever we can reduce the total number of
volumes, it will increase the speed. He is currently modifying the TOF
counters in GSIM so that all of the lead volumes around the
scintillators can be turned off with a switch. This may be an option
we want for other volumes as well.
There was a general discussion of the OPTI option. This option uses
GSORD to optimize GEANT tracking through volumes along a particular
axis. One could imagine using this option for the radial direction in
spherical coordinates in CLAS. The details of its use appear a bit
involved; John Price volunteered to look into this.
There was a further discussion of the use of the 'many/only'
characteristic of a volume in GSIM. Inappropriate use of the 'many'
option can slow the code down without benefit. David Rowntree agreed
to review how we are presently using this in GSIM.
I suggested to David at one point that we make a test to determine
whether most of the showers near the beamline are contained within the
minitorus and its shielding, or whether these are spraying into the DC
volume and are tracked there. He did a preliminary test using the
following: he counted calls to GTNEXT for a given set of input events;
there were 1,000,000 for default conditions. Then he turned off the
minitorus geometry, and lost 260,000 of these. If he turns off LAS2
geometry, (detectors and torus, but not EC1), he loses 165,000. If he
turns off DC, he loses 110,000. The interpretation of these numbers is
a little complicated, since turning the geometry off permits the
particles to travel further and shower in the next available structure.
My interpretation of the above is that (a) most of the steps are
somewhere else, i.e. the OTHE volume, (b) the majority of the
remaining steps are taken within the minitorus volume, and (c) most of
the remainder of the steps are in the drift chambers. The number of
steps
in the forward calorimeter appears from these numbers to be small,
i.e. an upper bound is 165,000 - 110,000 = 55,000 out of a million,
and only one-third as many as in the drift chambers. It may be
instructive to do the same test with no secondaries rather than
turning off the geometry.
Laurent posed the question as to how important all these events which
shower in support structures are, when we're only trying to calculate
acceptances. This is an important question since so much time is spent
on these events. Cole said in his studies of trigger problems that
it does occur that we get triggers from these events (see his very
nice study at http://apollo.phys.virginia.edu/clas/sim.html). It is
not clear how many of these survive a fiducial cut. Another effect is
the event-related multiplicity in the drift chambers, which may affect
the reconstruction efficiency (although the target-related
multiplicity is greater, it's uncorrelated with the track). If the
simulation is good enough, we will calculate a combined acceptance and
efficiency.
David reiterated that it would be efficient to increase the step size
for particles which interact with a non-active volume, if we knew a way
to do this.
There was a strong sentiment among the group that we need to generate
a large data set soon, if only to discover how it compares to the data
using high statistics. If there are no obvious barriers discovered, we
could aim for this on, say, the week of April 13.
ITEM 4 - BUG REPORT FOR GSIM - Cole Smith
Cole discovered a problem with the SC geometry which misplaces the SC
paddles relative to the other detectors and causes some overlap of the
paddles. Maurik is nearly finished with a complete re-write of the SC
geometry, and he was fairly sure he understood what the current
problem is. Only angles greater than 90 degrees are affected, and
perhaps only panel 4's. Maurik said he would check in his new code
soon and that it would fix the problem.
ITEM 5 THOUGHTS ON LONG-TERM REQUIREMENTS FOR ACCEPTANCE CALCULATIONS
- Will Brooks
The discussion was presented from the following web page:
http://www.jlab.org/~brooksw/gsim/future_requirements_acceptance.html
There were two points: 1) We definitely need at least one more Monte
Carlo bank, and 2) we need an accounting system to keep track of the
actions of programs such as GSIMKO and TSIM.
1) We need at least one more Monte Carlo bank to store information
such as: a) event weight
b) trigger flag
c) GSIMKO flag
d) other flags
A tentative name for this bank is MCX, for Monte Carlo eXtra bank.
We may also need yet another such bank to keep, e.g, partial wave
information.
2) If you think about the details of using codes like GSIMKO and TSIM,
it becomes obvious that we need an accounting system. For instance,
in this scheme, the CLAS acceptance in detail depends on *which* data
files you intend to analyze, i.e. the acceptance is a function of
time. This is because of effects like the DC 'holes' which are
present for some runs and not others.
The fraction of events to which GSIMKO's dead channel map should be
applied should reflect the fraction of the luminosity taken with
that particular dead channel map.
Another option, suggested by David Rowntree, is to just change the
weights of the events to correct for the proper luminosity
fraction. This simplifies the bookkeeping, but gives slightly
incorrect statistical errors when all the data is combined
together.
A scheme which makes the bookkeeping reasonably easy is to have
each program which 'processes' the data, like GSIMKO and TSIM, to
set a flag on each event. The flag could live in the MCX bank
mentioned above. The flag could contain information, such as the
trigger type used by TSIM or the version number of the code.
There was not a consensus about this plan; I agreed to try to come
up with a list of what quantities we need to include in the MCX
bank.
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)
- Franz Klein (JLAB) 757-269-5829 fklein@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) 804-924-6806 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)