[SBS_sim] Cluster plots

Thu Feb 10 07:20:56 EST 2011

Dear Evaristo,

thanks for the quick response and the explanations. I think I understand 
the entire structure of the file now, and I'll be able to get the track 
information out of the hit data. The particle momentum is actually 
better than directional angles.

Extracting the truth information about the incoming track in this way is 
a bit indirect and not totally free from the (probably small) scattering 
effects in the material, though. Perhaps when you have a chance to do it 
before the next larger production (at the new spectrometer angle), could 
you extract the proton track data in a fixed reference plane and add 
that information to the ROOT file? I realize that you'll have to re-run 
the MC, so do it when convenient. I can work with the g16 file for now.

Cheers,

Ole

Evaristo Cisbani wrote:
> 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
>>>>
>>>
> 