[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tracks with no hits.
Hi Richard,
I have run across a mystery that I think you may be the only person
who can solve it. Recently (~ 1 month ago), I ran a simulation to map
out the efficiency and resolution for charged particle tracking using
the latest geometry and tracking code. One of the things that showed up
was an odd structure in the efficiency map (in ptot and theta) where
there was a several percent loss in efficiency in a thin band that
appears to be for a constant transverse momentum (though now, I'm sure
that is actually the case). Mark Ito repeated the exercise with his
independent fitter and found the same result.
I ran a few events with the particle gun aimed at the low-efficiency
area and I found that for some tracks (several percent) there were no
hits at all. I turned on the DMCTrajectoryPoints which record the track
parameters at every call to gustep, including the radiation length of
the material they are passing through. I could see that the particles
were going through the detector, but for the problem events, the
radiation length was always very large (30k cm) indicating that it never
left the gas. For good events, I could see it getting smaller
occasionally, presumably as it passed through the straw tube walls. I'm
wondering if this is a MANY/ONLY problem, but I'm not sure where to
begin in order to figure it out. Oh, and I also saw this same thing for
some forward going tracks that were passing through the FDC.
I've attached a control.in file that shows the problem on events 6,
25, 32, 46, ... I have verified that I see the problem on event 6 on
both Mac OS 10.5 and Fedora 8. I am using the source code tagged for a
special study that can be found here:
https://halldsvn.jlab.org/repos/trunk/Studies/2009.02.track_resolutions/src
This contains the complete source tree including hdds and HDGeometry and
HDDM so you should be able to reproduce exactly what I'm doing.
Could you maybe look into this when you get a chance?
Regards,
-David
--
------------------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist Office: (757)269-5567 [[[ [ [ [
Jefferson Lab Pager: (757)584-5567 [ [ [ [ [ [
http://www.jlab.org/~davidl davidl@jlab.org [[[ [[ [[ [[[
------------------------------------------------------------------------
c This is the control file for the GEANT simulation. Parameters defined
c in this file control the kind and extent of simulation that is performed.
c The full list of options is given in section BASE-40 of the GEANT manual.
c
c In addition, some new cards have been defined to set up the input source
c for the simulation. Three kinds of simulation runs are available, selected
c by which of the following three "cards" are present below.
c 1. Input from Monte Carlo generator (card INFILE)
c 2. Built-in coherent bremsstrahlung source (card BEAM)
c 3. Built-in single-track event generator (card KINE)
c The order of the list is significant, that is if INFILE is present then the
c BEAM and KINE cards are ignored, otherwise if BEAM is present then KINE is
c ignored. For example, the 3-card sequence:
c INFILE 'phi-1680.hddm'
c SKIP 25
c TRIG 100
c instructs HDGeant to open ./phi-1680.hddm, skip the first 25 events and then
c process the following 100 input events and stop. If the end of the file is
c reached before the event count specified in card TRIG is exhausted then the
c processing will stop at the end of file.
TRIG 1000
cINFILE 'dummy_inputXXX.hddm'
cBEAM 12. 9.
RUNG 9999
c Commenting out the following line will disable simulated hits output.
OUTFILE 'hdgeant_theta90p259.hddm'
c The following card enables single-track generation (for testing).
c For a single-particle gun, set the momentum (GeV/c), direction
c theta,phi (degrees) and vertex position (cm), and for the particle
c type insert the Geant particle type code plus 100 (eg. 101=gamma,
c 103=electron, 107=pi0, 108=pi+, 109=pi-, 114=proton). If you use
c the particle code but do not add 100 then theta,phi are ignored
c and the particle direction is generated randomly over 4pi sr.
c For a listing of the Geant particle types, see the following URL.
c http://wwwasdoc.web.cern.ch/wwwasdoc/geant_html3/node72.html
c The meaning of the arguments to KINE are as follows.
c - particle = GEANT particle type of primary track + 100
c - momentum = initial track momentum, central value (GeV/c)
c - theta = initial track polar angle, central value (degrees)
c - phi = initial track azimuthal angle, central value (degrees)
c - delta_momentum = spread in initial track momentum, full width (GeV/c)
c - delta_theta = spread in initial track polar angle, full width (degrees)
c - delta_phi = spread in initial track azimuthal angle, full width (degrees)
c
c particle momentum theta phi delta_momentum delta_theta delta_phi
KINE 108 0.259 90.0 0. 0.0 0. 360.
c The SCAP card determines the vertex position for the particle gun. It
c supports the following three arguments, all of which default to 0.
c
c vertex_x vertex_y vertex_z
SCAP 0. 0. 65.
c If you specify a non-zero value for vertex_x and/or vertex_y above then
c all tracks will emerge from the given point. If you leave them at zero,
c you have the option of specifying the HALO card which causes the simulation
c to generate events with a transverse profile modeled after the 12 GeV
c electron beam. The argument only argument to HALO is fhalo, the fraction
c of the beam that lies in the halo region surrounding the core gaussian.
c The nominal value taken from CASA technical note JLAB-TN-06-048 is 5e-5.
c This card is only effective for electron beam simulations with gxtwist.
c
c fhalo
HALO 5e-5
c The following lines control the rate (GHz) of background beam photons
c that are overlayed on each event in the simulation, in addition to the
c particles produced by the standard generation mechanism. A value of
c 1.10 corresponds to nominal GlueX running conditions at an intensity of
c 10^7 tagged photons on target per second. To disable the generation of
c random beam background, comment this line out or set the value of BGRATE
c to zero. Background beam photons are generated during the time interval
c given by the BGGATE card, whose two arguments specify the earliest and
c latest times (ns relative to the time of the original photon that caused
c the event) that a random beam photon could produce background hits
c somewhere in the detector. Note that for this to work, the BEAM card
c must be present (see above). This means that background generation is
c disabled when the simulation operates in particle gun mode.
BGRATE 1.10
BGGATE -100. 900.
c The following card seeds the random number generator so it must be unique
c for each run. There are two ways to specify the random see for a run.
c 1. One argument, must be an integer in the range [1,215]
c 2. Two arguments, must be a pair of positive Integer*4 numbers
c In the first case, one of a limited set of prepared starting seeds is
c chosen from a list. These seeds have been certified to produce random
c sequences that do not repeat within the first 10^9 or so random numbers.
c For cases where more choices are needed, the two-argument form gives
c access to a total of 2^62 choices, with no guarantees about closed loops.
RNDM 3 1
c The following line controls the cutoffs for tracking of particles.
c CUTS cutgam cutele cutneu cuthad cutmuo bcute bcutm dcute dcutm ppcutm tofmax
c - cutgam = Cut for gammas (0.001 GeV)
c - cutele = Cut for electrons (0.001 GeV)
c - cutneu = Cut for neutral hadrons (0.01 GeV)
c - cuthad = Cut for charged hadrons (0.01 GeV)
c - cutmuo = Cut for muons (0.01 GeV)
c - bcute = Cut for electron brems. (CUTGAM)
c - bcutm = Cut for muon brems. (CUTGAM)
c - dcute = Cut for electron delta-rays. (10 TeV)
c - dcutm = Cut for muon delta-rays. (10 TeV)
c - ppcutm = Cut for e+e- pairs by muons. (0.01 GeV)
c - tofmax = Time of flight cut (1.E+10 sec)
c - gcuts = 5 user words (0.)
CUTS 1e-4 1e-4 1e-3 1e-3 1e-4
c The following line controls a set of generic flags that are used to
c control aspects of the simulation generally related to debugging.
c For normal debugging runs these should be left at zero (or omitted).
c At present the following functionality is defined (assumes debug on).
c SWIT(2) = 0 turns off trajectory tracing
c = 2 turns on step-by-step trace during tracking (verbose!)
c = 3 turns on trajectory plotting after tracking is done
c = 4 turns on step-by-step plotting during tracking
c SWIT(3) = 1 stores track trajectories for plotting after tracking is done
c SWIT(4) = 0 trace trajectories of all particle types
c = 3 trace only charged particle trajectories
SWIT 0 0 0 0 0 0 0 0 0 0
c The following card enables the GelHad package (from BaBar)
c on/off ecut scale mode thresh
GELH 1 0.2 1.0 4 0.160
c The following card selects the hadronic physics package
c HADR 0 no hadronic interactions
c HADR 1 GHEISHA only (default)
c HADR 2 GHEISHA only, with no generation of secondaries
c HADR 3 FLUKA (with GHEISHA for neutrons below 20MeV)
c HADR 4 FLUKA (with MICAP for neutrons below 20MeV)
c The following cards are needed if optical photons are being
c being generated and tracked in the simulation. The CKOV directive
c enables Cerenkov generation in materials for which the refractive
c index table has been specified. The LABS card enables absorption
c of optical photons. The ABAN directive controls a special feature
c of Geant which allows it to "abandon" tracking of charged particles
c once their remaining range drops below the distance to the next
c discrete interaction or geometric boundary. Particles abandoned
c during tracking are stopped immediately and dump all remaining energy
c where they lie. The remaining energy is dumped in the correct volume
c so this is OK in most cases, but it can cut into the yield of
c Cerenkov photons (eg. in a lead glass calorimeter) at the end of
c a particle track. If this might be important, set ABAN to 0.
MULS 0
LOSS 0
DCAY 0
PAIR 0
COMP 0
PHOT 0
BREM 0
DRAY 0
ANNI 0
HADR 0
ECOH 0
EVAP 0
FISS 0
ABSO 0
ANNH 0
CAPT 0
EINC 0
INHE 0
MUNU 0
PFIS 0
RAYL 0
LABS 0
LREF 0
CKOV 0
REFL 0
REFR 0
SYNC 0
c The following card prevents GEANT tracking code from abandoning the
c tracking of particles near the end of their range, once it determines
c that their fate is just to stop (i.e. electrons and protons). This
c behaviour is normal in most cases, but in the case of Cerenkov light
c generation it leads to an underestimate for the yields.
c ABAN 1 abandon stopping tracks (default)
c ABAN 0 do not abandon stopping tracks
ABAN 0
c The following card sets up the simulation to perform debugging on
c a subset of the simulated events.
c DEBUG first last step
c - first (int) = event number of first event to debug
c - last (int) = event number of last event to debug
c - step (int) = only debug one event every step events
c DEBUG 1 10 1000
c The following card can be used to turn off generation of secondary
c particles in the simulation, ordinarily it should be 0 (or omitted).
NOSECONDARIES 1
c The following card tells the simulation to store particle trajectories
c in the event output stream. This output can be verbose, use with caution.
c The value set here determines the amount of output recorded:
c
c TRAJECTORIES = 0 don't store trajectory info
c TRAJECTORIES = 1 store birth and death points of primary tracks
c TRAJECTORIES = 2 store birth and death points of all particles
c TRAJECTORIES = 3 store full trajectory of primary tracks
c TRAJECTORIES = 4 store full trajectory of primary tracks and birth/death points of secondaries
c TRAJECTORIES = 5 store full trajectory for all particles
c
TRAJECTORIES 5
c The following tracking parameters are defined for each tracking medium
c TMAXFD (REAL) maximum angular deviation due to the magnetic field
c permitted in one step (degrees)
c DEEMAX (REAL) maximum fractional energy loss in one step (0< DEEMAX <=0.1)
c STEMAX (REAL) maximum step permitted (cm)
c STMIN (REAL) minimum value for the maximum step imposed by energy loss,
c multiple scattering, Cerenkov or magnetic field effects (cm)
c Normally they are assigned appropriate values calculated automatically by
c Geant when the geometry is defined, overwriting the values declared by
c the user code in the GSTMED() call. Users who know what they are doing can
c force Geant to instead use the values passed in the arguments to GSTMED()
c by removing the comment in front of the following card. Any parameters with
c zero values are still assigned automatic values even when AUTO is turned off.
cAUTO 0
END