[SBS_sim] Cluster plots

[Ole Hansen]

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.

> 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.


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
>>
> 
>