[Halld-offline] DBCALTruthShowers
Richard Jones
richard.t.jones at uconn.edu
Mon Oct 20 13:42:10 EDT 2014
Justin,
I see no reason why it should be provisional. Can you think of any other
truth information that is currently missing that you would find useful?
-Richard Jones
On Mon, Oct 20, 2014 at 1:04 PM, Justin Stevens <jrsteven at mit.edu> wrote:
> Hi Richard,
>
> Thanks again for another fix.
>
> For recommendation 1, I didn't see before this subtly between the 'track'
> and 'itrack' indexing of the truth information. I agree completely that we
> shouldn't change the meaning of the 'track' attribute, but I think it would
> be useful to have the 'itrack' attributes for the TruthShowers/Points which
> index the MC geneology through MCThrown to better understand the matching
> between MC and reconstructed objects.
>
> Your suggestion to add 'itrack' to the TruthShowers/Points sounds like the
> right thing to me. I don't want to disrupt the commissioning studies
> ongoing now as they're clearly higher priority, but if the inner tag is a
> non-disruptive solution that's fine with me as well. Would that be a
> permanent solution, or would it be preferred to eventually remove the inner
> tags and add this attribute directly to the TruthShower/Point tags later?
>
> -Justin
>
> On Oct 20, 2014, at 11:42 AM, Richard Jones wrote:
>
> > Hello Justin,
> >
> > I agree 100% with your recommendation 2, and have checked in a fix for
> this.
> >
> > For your recommendation 1, I think this needs further discussion. In the
> hddm hitView record we currently distinguish between these MCThrown lookup
> indices and the Geant track index scheme set up by Beni by using the
> attribute "itrack" for the former and "track" for the latter. If you look
> through the hddm header, you can see that there are many instances of each
> of these in the truth information tags. I have not done a study of this,
> but I guess that there are multiple places in various analysis codes that
> make use of the "track" information as such, and also the "itrack" info as
> such. In general I see "track" indices recorded for the TruthPoint and
> TruthShower tags, whereas "itrack" indices are recorded for TruthHits and
> for the bcal TruthFADC tags.
> >
> > One thing we might consider is to go through the TruthShower and
> TruthPoint tags and add new itrack attributes in addition to the existing
> track index. This would involve changing the hddm model, which might be
> disruptive in the near term. I could add an inner tag within the
> TruthShower / TruthPoint tags just to contain the itrack, and doing it that
> way would maintain compatibility with the existing generated files. What I
> don't want to do is to change the meaning of existing attributes called
> "track" without changing the name.
> >
> > -Richard Jones
> >
> > On Mon, Oct 20, 2014 at 9:05 AM, Justin Stevens <jrsteven at mit.edu>
> wrote:
> > Hi Richard, All,
> >
> > Thanks for the fix and reporting it here. I would like to propose two
> additional changes:
> >
> > 1) When the scheme for keeping track of particle geneology was updated
> last year, hitCDC.c and hitFDC.c were changed to label the truth hits by
> their global track ID in the new scheme instead of the internal geant track
> ID. I suggest we do the same for hitBCAL.cc and hitFCAL.c using something
> like
> >
> > showers->in[0].track = gidGetId(track);
> >
> > This way the truth showers can be matched to DMCThrown objects and their
> parentage tracked accurately in more complicated events (eg. bggen).
> >
> > 2) In gustep.F there are two places (code pasted at the bottom of this
> message) where particles are checked to be in the BCAL or FCAL to decide
> whether to: a) place secondaries on the stack and b) save the vertex and
> decay particles.
> >
> > Currently, the checks for the BCAL is if radius < 65 and
> (cnames(NLEVEL).ne.'BCAL'). To be consistent with the correction for the
> aluminum plate on the front of the BCAL, I think these should be changed to
> radius < 64.2485 (?) and
> (cnames(NLEVEL).ne.'BCAL').and.(cnames(NLEVEL).ne.'BCAM'). Do you agree?
> >
> > Thanks,
> > Justin
> >
> > gustep.F code snippet:
> >
> > * Place any secondaries generated during this step onto the stack
> >
> > if (nosecondaries.eq.0) then
> > do i=1,NGKINE
> > c make primary except if in calorimeter volume and not hadronic
> > c interaction, or except if produced in cave upstream of Hall D
> > iflgk(i) = 1
> > cint = KCASE
> > rx = sqrt(VERT(1)**2+VERT(2)**2)
> > if ((((rx>65.).and.((VERT(3)>-17.).and.(VERT(3)<390.))) !BCAL
> > > .or.(VERT(3)>625.) !FCAL
> > > .or.(VERT(3)<-500.)) !CAVE
> > > .and.(cchar.ne.'HADR')) then
> > iflgk(i) = 0
> > endif
> > call GSKING(i)
> > enddo
> > endif
> >
> > * check if particle did decay in which case save vertex and particles
> >
> > if (ISTOP .eq. 1) then
> > mechanism = KCASE
> > if ((NGKINE>0) .and. (chcase.eq.'DCAY')) then
> > if ((cnames(NLEVEL).ne.'BCAL').and.
> > + (cnames(NLEVEL).ne.'FCAL').and.
> > + (sqrt(VERT(1)**2+VERT(2)**2)<65.).and.
> > + (VERT(3)<500.).and.(VERT(3)>-500.)) then
> > call savenewvertex(KCASE,NGKINE,GKIN,VECT,
> > + TOFG,iflgk,IPART,ITRA,ISTAK)
> > endif
> > endif
> > endif
> >
> > On Oct 17, 2014, at 7:12 PM, Richard Jones wrote:
> >
> > > Hello Justin,
> > >
> > > You are right to be surprised by this behavior. It was not there when
> I first set up this "truth shower" recording mechanism in hdgeant. I looked
> into it, and was able to reproduce what you are seeing.
> > >
> > > The problem is unique to the bcal. It came about primarily (there was
> another minor issue that I fixed at the same time, that will reduce the
> fragmentation of the fcalTruthShower info as well) because at some point we
> added a relatively thick aluminum structure to the front of the bcal, which
> serves as a primary mechanical support for the module. Because of its
> thickness, a large fraction of the incident gammas convert and preshower in
> this aluminum bar, and so what actually reaches the first active layer of
> the bcal is often a gazillion low-energy shower particles clustered around
> the incident gamma direction. That is why you were seeing fragmentation in
> the bcalTruthShower tags.
> > >
> > > I added a fix to gustep.F in the HDGeant directory in both the trunk
> and commissioning branches. Please check out the latest update of whichever
> you are using and try it. This code catches any particles incident on the
> bcal and records the TruthShower info before they enter the aluminum
> support beam. There are still a few conversions that take place in the CDC
> and the FDC cables around the CDC, but you should see that most of your 2
> GeV gammas at 50 degrees now generate just a single bcalTruthShower in
> hdgeant. For those that shower in the CDC and FDC cable material, I think
> we should not try to merge them into a single bcalTruthShower because the
> magnetic field will have a significant dispersive effect on them.
> > >
> > > Thank you for reporting this problem. I hope this helps with bcal
> reconstruction.
> > >
> > > -Richard Jones
> > >
> > > On Tue, Oct 14, 2014 at 3:30 PM, Justin Stevens <jrsteven at mit.edu>
> wrote:
> > > Hi Richard,
> > >
> > > I was hoping to follow up on what we talked about briefly at the
> collaboration meeting regarding BCAL truth showers. I'm looking at some
> simulation events with single photons generated at theta = 50 degrees and E
> = 2 GeV. From an earlier thread about hadronic showers on the offline list
> https://mailman.jlab.org/pipermail/halld-offline/2014-May/001677.html
> > >
> > > > Once a primary particle has entered the BCAL and had its TruthShower
> recorded, it is marked with a spot of red dye (colloquially). Any
> secondaries that are generated from interactions by that particle inherit
> its red spot, even if they escape from that module and enter another one.
> > >
> > >
> > > I was expecting there should be only one BCAL truth shower in each
> event which contain a single photon. This is the case for some events like
> this one from hd_dump:
> > >
> > > DBCALTruthShower:
> > > ptype: track: primary: phi: r: z: t: p: E:
> > > -------------------------------------------------------------------
> > > 1 1 1 -1.419 65.042 119.6 2.832 2.000 2.000
> > >
> > > However, for most events there are many DBCALTruthShowers listed, like
> in the example below:
> > >
> > > DBCALTruthShower:
> > > ptype: track: primary: phi: r: z: t: p: E:
> > > ------------------------------------------------------------------
> > > 1 1 1 0.686 65.042 119.6 2.832 2.000 2.000
> > > 3 3 0 0.686 66.617 120.9 2.901 1.595 1.595
> > > 3 3 0 0.686 66.979 121.2 2.917 0.001 0.001
> > > 1 3 0 0.686 66.766 121.0 2.907 0.054 0.054
> > > 2 2 0 0.686 66.617 120.9 2.901 0.405 0.405
> > > 1 2 0 0.686 66.894 121.1 2.913 0.018 0.018
> > > 1 2 0 0.686 66.806 121.1 2.909 0.005 0.005
> > > 1 2 0 0.686 66.709 121.0 2.905 0.201 0.201
> > > 3 2 0 0.686 67.005 121.2 2.918 0.158 0.158
> > > 1 2 0 0.686 67.021 121.2 2.918 0.068 0.068
> > > 2 2 0 0.686 67.005 121.2 2.918 0.042 0.042
> > > 1 2 0 0.686 67.060 121.3 2.920 0.016 0.016
> > > 1 2 0 0.686 67.021 121.2 2.918 0.001 0.001
> > >
> > > So first of all, is this the expected behavior? That there are many
> DBCALTruthShowers where many of them appear to be secondaries of the
> primary single generated photon in the event?
> > >
> > > And if the answer to the questions about is yes, for a general bggen
> event (where there are many particles incident to the BCAL) how should I
> best associate reconstructed BCAL showers with these DBCALTruthShowers?
> > >
> > > Thanks,
> > > Justin
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20141020/72fbba5c/attachment-0002.html>
More information about the Halld-offline
mailing list