[Halld-offline] DBCALTruthShowers
Justin Stevens
jrsteven at mit.edu
Mon Oct 20 14:08:32 EDT 2014
Hi Richard,
I can't think of anything else for the TruthShowers/Points at the moment.
-Justin
On Oct 20, 2014, at 1:42 PM, Richard Jones wrote:
> 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
> > >
> >
> >
>
>
More information about the Halld-offline
mailing list