Re: [BLAST_ANAWARE] question: how to link hit detectors with particles in the mc

From: Simon Sirca (simon.sirca@fmf.uni-lj.si)
Date: Wed Sep 15 2004 - 07:45:25 EDT


Hi everybody,

one thing I would be very careful about in this "turn all physics OFF"
approach is charged pions decaying to muons. I guess we all wish to
see pions quickly, but I don't believe a short cut is possible here.
It is hard to distinguish pi from mu by TOF, and virtually impossible
by dE/dx of any kind, and the decay is anything but forward-peaked,
plus it gets very complicated tracking-wise. What do you do with
tracks where a pi+ flies from the target, then decides to decay
somewhere between the first and second chamber package, emitting
a muon, say, 30 deg away of the original pion momentum? When the muon
finally triggers the scint (and maybe it doesn't because it is bent
out of the acceptance azimuthal- or polar-wise), what PID assignment
can you make?

Bypassing geant here, to my opinion, is dangerous, and I think Michael
will back me up this time.

Simon

 
On Tue, 14 Sep 2004, Chi Zhang wrote:

>
> Hi Aaron,
>
> if anyone has not replied with this yet.
>
> I think this is exactly what Simon was pointing to in his message. But I
> think we would be able to work arround it and the work arround I can think
> of is simply turn all the physics OFF. And also turn the 200um wire
> resolution OFF for sake of run time.
>
> then a neutron will remain a neutron, never turn into two neutrons and a
> gamma. Since we are going to stick in resolution by hand, instead of using
> the MC data for reconstruction, energy loss, multiple scatterin, hadronic
> interaction and detector resolution simply don't matter. I can't think
> of any place they play a role in the new "scheme of simulation". All we
> need is knowing the damn track passed through 18 wires.
>
> Chi
>
> On Mon, 13 Sep 2004, Aaron Joseph Maschinot wrote:
>
> >
> > in the new monte carlo formalism, a text file named 'event.dgen' will be
> > generated which will include, among other things, the detectors that each
> > particle in the specified reaction hits. for acceptance studies, it
> > is necessary to link the hit detector information with the identity of
> > the particle hitting it (else we have to use the reconstruction to do
> > so, which contradicts the reason for this formalism). this sounds cut and
> > dry.
> >
> > however, some confusion arises when particle-disintegration/transformation
> > physics processes (e.g. pair production and hadronic interactions) are
> > included. for example, in a LAD, it's possible that a neutron will
> > transform into a neutron and a gamma, into two neutrons and a gamma, into
> > a proton, an electron, and a gamma, etc.
> >
> > my question is this: what should be recorded to event.dgen? currently, i
> > have it setup so that all detectors hit by one of the event-originating
> > particles (at the target) are recorded. however, as soon as a reaction
> > happens that causes GEANT to start a new track (e.g. GEANT would consider
> > the two neutrons in n --> n + gamma to be separate tracks and particles),
> > i stop recording.
> >
> > so, what is the preferred way of recording here:
> >
> > 1) record hits until a GEANT-recognized particle disintegration/
> > transformation occurs
> >
> > 2) record all hits from all particles originating from any particular
> > event-origin particle (thus, e.g., in d + e --> e' + p + n followed
> > by n --> n + n + gamma, all detectors hit by either neutron or the
> > gamma would be recorded as being hit by the original neutron)
> >
> > 3) record all hits from "like" particles originating from any
> > particular event-origin particle (thus, e.g., in the example above in
> > 2), only detectors hit by a neutron (either one), but not the gamma,
> > would be recorded as being hit by the original neutron)
> >
> > 4) else ???
> >
> > aaron
> >
>

--
  Simon Sirca
  Dept of Physics, University of Ljubljana   Tel: +386 1 4766-574
  Jadranska 19                               Fax: +386 1 2517-281
  1000 Ljubljana, Slovenia                   



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST