[SBS_sim] Cluster plots
Evaristo Cisbani
evaristo.cisbani at iss.infn.it
Thu Feb 10 04:04:45 EST 2011
Dear Ole,
My comments are below.
On Wed, 2011-02-09 at 15:07 -0500, Ole Hansen wrote:
> Hi Evaristo,
>
> thanks for doing the checks. This is useful information. My comments below.
>
> Evaristo Cisbani wrote:
> > Dear Ole,
> >
> > the "barn door" distribution of x (and y) is correct. The Montecarlo is
> > configured to generate trajectory in a small aperture, around the center
> > of the tracker (which may have an offset).
> >
>
> A distribution of incoming tracks is no problem. I am just joking with
> the "barn door" description. However, in order to evaluate the
> reconstruction performance precisely, it is necessary to have the exact
> position and angle of the incoming track. As far as I can see, this
> information is not yet in the ROOT files from your production.
>
> I was wondering if you could run the g15 production with 0% background
> again, this time including the information about the proton track that
> is incident on the tracker. What we need is, on an event-by-event basis,
>
> - proton track x and y position (let's say, in meters) at z=0, where z=0
> is defined as the z-position of the front layer of the first GEM readout
> plane.
>
> - track directional angles theta and phi (preferably the tangents
> thereof). These would be the angles of the track projection into the x-z
> and the y-z planes with respect to the z-axis. A perfectly perpendicular
> track would have both angles at zero. With this definition, the track
> position at some z-coordinate Z are x(Z) = x(0) + theta*Z and y(Z) =
> y(0) + phi*Z.
>
> - track momentum (GeV)
>
> These track parameters should be the ones before any interaction with
> materials in the GEMs. Depending on the geometry, you might need to
> extract them in a plane a short distance before the first GEM plane,
> before interaction takes place, and then project forward to z=0.
>
I put on:
http://www.iss.infn.it/cisbani/atmp/gemc/production/g16/0/
the g15 production "re-digitized" (0 background) with the information
you need (not exactly the same):
digi.gem.hit.mx // momentum particle generating the hit (x component)
digi.gem.hit.my // momentum particle generating the hit (y component)
digi.gem.hit.mz // momentum particle generating the hit (z component)
digi.gem.hit.x // hit entrance (x component, local coordinate)
digi.gem.hit.y // hit entrance (y component, local coordinate)
digi.gem.hit.z // hit entrance (z component, local coordinate)
they basically are the momentum and the position of the hits on the
drift gap of each chamber (there is air and 3 mm honeycomb before the
drift gap); to select the first chamber:
digi.gem.hit.chamber==0
Let me know if this is enough, otherwise I need to modify a little bit
the Montecarlo and rerun both MC and Digitization
> > If you cut out clusters with single hit, do you improve the reconstruction ?
>
> No, that doesn't help. The efficiency goes down. That's not surprising
> because if we omit these clusters, many tracks have a lot of planes
> without hits and exceed the maximum allowed number of missing hits.
>
> The way I now treat the 1-strip clusters is to assign them a larger
> position uncertainty.
>
> > Concerning the digitization of x and y, they are actually slightly
> > different (we tried to simulate the real strips which are different). I
> > cannot say that the difference you found are realistic; in any case the
> > size distribution look reasonable.
> >
> > I checked the alignment of the generate hits, before digitization
> > (production g15, no background). In the first attached file (hit_track
> > ...) you find the distribution of the sum of the distances (squared) of
> > the hits from the best fitted line. The values looks very small for most
> > of the tracks (about 89 %). No cuts applied.
> >
> > In the second file (clus_track ...) I tried to figure out how the
> > digitization perturb the alignment: I used the size of the clusters (in
> > number of strip) and the position of the first strip in the cluster to get
> > the position of the cluster (no charge weighting). As before, the
> > distribution of the sum of the distances (squared) of the cluster center
> > from the best line in unit of strip. Apparently the distribution is
> > reasonable and compatible with the previous plot (the width of the
> > distribution is below 1 strip).
> >
> > Do you use the charge information to get the cluster centroid ? If
> > positive, could you try without charge: assume the middle of the cluster
> > as cluster center, and see if it improve ?
>
> We use the charge to compute a weighted average. I will try using the
> geometrical center and see what I get.
>
> Let me know if you can do the new production with the track info added
> in the ROOT file. For the moment, we only need 0% background.
>
> BTW, the following variables in the ROOT file are unclear to me. Do you
> have a quick description for them, at least for the ones that might be
> relevant for the reconstruction?
>
> digi.gem.nsignal (I think I understand nhit and nch, but what is this?)
>
> digi.gem.hit.mcentry
> digi.gem.hit.mcfile
> digi.gem.hit.pID
> digi.gem.hit.mx
> digi.gem.hit.my
> digi.gem.hit.mz
> digi.gem.hit.size0 ("0" refers to x? y?)
> digi.gem.hit.size1
> digi.gem.hit.strip0 (number of first strip?)
> digi.gem.hit.strip1
>
> digi.gem.time1
>
> Also, is there any link between the hits and the clusters? Maybe each of
> the nch clusters could have a list of hit numbers that contribute to the
> cluster. In that way, we could fully decompose the clusters during
> replay and use the information for diagnostics/event display etc.
>
Here are the descriptions of the variables:
digi.gem.nhit // total number of hits (from the MonteCarlo) no digitization applied yet
digi.gem.nsignal // number of hits of signal (hits from signals are the first nsignal entries of each event)
digi.gem.hit.mcentry[digi.gem.nhit] // reference entry in mc root file
digi.gem.hit.mcfile[digi.gem.nhit] // reference file in mc (combined with the above can be used to look at the Montecarlo raw data)
digi.gem.hit.pID[digi.gem.nhit] // particle ID (PDG code) generating the hit
digi.gem.hit.mx[digi.gem.nhit] // momentum particle generating the hit (x component)
digi.gem.hit.my[digi.gem.nhit] // momentum particle generating the hit (y component)
digi.gem.hit.mz[digi.gem.nhit] // momentum particle generating the hit (z component)
digi.gem.hit.x[digi.gem.nhit] // hit entrance (x component, local coordinates)
digi.gem.hit.y[digi.gem.nhit] // hit entrance (y component, local coordinates)
digi.gem.hit.z[digi.gem.nhit] // hit entrance (z component, local coordinates)
digi.gem.hit.time[digi.gem.nhit] // time of arrival of the signal into the electronics (time of flight not included yet)
// the following variable link the hit to the cluster
digi.gem.hit.size0[digi.gem.nhit] // number of strips in cluster/hit on first axis (x)
digi.gem.hit.size1[digi.gem.nhit] // number of strips in cluster/hit on second axis (y)
digi.gem.hit.strip0[digi.gem.nhit] // address of first strip of the cluster on first axis (x)
digi.gem.hit.strip1[digi.gem.nhit] // address of first strip of the cluster on second axis (y)
for each of the above arrays, the first digi.gem.nsignal elements belongs to proton (signal); in case of zero background,
digi.gem.nsignal = digi.gem.nhit
There is no direct link between hit and cluster.
However from the above digi.gem.hit.strip0 and strip1 as well as size0 and size1 you can indirectly decompose the cluster:
that is: assume the cluster is made of some digi.gem.strip[...];
if (let consider the x coordinate) digi.gem.strip >= digi.gem.hit.strip0 and digi.gem.strip < (digi.gem.hit.strip0 + digi.gem.hit.size0)
the hit belongs to the cluster
digi.gem.time1 gives the first sampling start time relative to the trigger: it include the drift time of the avalanche in the GEM.
in case of background it is randomly generated around -400 ns and + 75 ns (should be 25 ns * number of samples
therefore, only for a pure signal strip: digi.gem.time1 \sim 0;
Evaristo
>
> Best,
>
> Ole
>
>
> > Cheers,
> > Evaristo
> >
> >
> >
> >
> >> Hi all,
> >>
> >> just to illustrate the issue with the cluster position a little bit,
> >> attached are plots of the calculated cluster center position in the x1
> >> and y1 planes for the g15 0%-background production. My observations
> >> (already made in December):
> >>
> >> x distribution is wide as a barn door, about 8 mm wide. The incident
> >> tracks definitely do not seem to be precisely centered on the chamber.
> >> This may be fine.
> >>
> >> y distribution is narrower (~3 mm), but shows very pronounced peaks
> >> separated by the strip pitch. Such peaks occur if a found "cluster"
> >> consists of only one strip because in that case no intermediate position
> >> between strips can be calculated.
> >>
> >> The next two plots show the sizes of the clusters whose positions are
> >> shown in the other plots. As already suspected, there is a significant
> >> number of y-clusters with only one strip. For this coordinate, I do see
> >> the average cluster size of 1.8 that Vahe mentioned on the phone.
> >>
> >> Lastly, I include the plot of the residuals (in y1) that I mentioned I
> >> showed in December. This one is for the g11 production (10% background).
> >> All the other plots are for g15/0%.
> >>
> >> The qualitative features of the cluster plots do not change if I require
> >> exactly one good track or similar obvious cuts. Also, the cluster plots
> >> are essentially identical for all 6 x and y planes. For planes further
> >> in the back of the spectrometer, one sees a slight widening of the
> >> x-distribution, perhaps due to scattering effects.
> >>
> >> My suspicion at this point is that the single-strip "clusters" in y are
> >> unsuitable input for track reconstruction. They cause the hit position
> >> artificially to "snap" to the fixed strip positions, which may often be
> >> 100s of um away from the crossing point of the track.
> >>
> >> Evaristo: could you comment on the discrepancy in position distribution
> >> and cluster size in x and y? Shouldn't both coordinates have at least
> >> identical cluster sizes? Or is such an asymmetry an intrinsic feature of
> >> the readout planes?
> >>
> >> Ole
> >> _______________________________________________
> >> SBS_sim mailing list
> >> SBS_sim at jlab.org
> >> https://mailman.jlab.org/mailman/listinfo/sbs_sim
> >>
> >
> >
--
Evaristo Cisbani office : +39 06 4990 2847
Istituto Superiore di Sanita` lab : +39 06 4990 2347
Department of Technology and Health fax : +39 06 4938 7075
and Istituto Nazionale di Fisica Nucleare Roma - gruppo Sanita`
via Regina Elena 299 - 00161 Rome web : www.iss.infn.it/cisbani
Italy
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2875 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/sbs_sim/attachments/20110210/e8cefbee/attachment.bin
More information about the SBS_sim
mailing list