You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Here are some notes for the june 10 tagup

Philippe's email report

I won't be able to attend the meeting today. Here is my short written report, based on the results I already posted (https://confluence.slac.stanford.edu/display/SCIGRPS/2010/06/02/First+look+to+periodic+trigger+events+responsible+for+the+loss+of+effective+area)

  • The production of OVRLY and FAKEOVRLY is very helpful to understand the reasons why overlay events prevent simulated events to pass the selection;
  • The tracker activity in a PT event is not the main problem : the cal and acd activities are more often the cause of the loss of the MC events
  • One of the main issue is the fact that the cal direction is is very badly reconstructed because of the PT additional crystals. As a consequence, the track is badly reconstructed as well.
  • This problem can only be solved by a smart clustering, able to find ghost clusters. This is not easy because the ghost clusters are very often large and not so clustered.
  • On top of that, when there is a ghost track, the ghost track and the ghost cluster are very often unrelated. It means that, in most cases, we can't use the ghost track to tag the ghost cluster.
  • All this should help us in defining/optimizing the cal clustering.

Some considerations about the clustering :

  • If there is a ghost track, we know how to find it and remove the ghost hits. It means that for all events, we can end up with a clean tracker information, i.e. hits only due to the main event. This clean tracker information points to the main cluster.
  • When there is a ghost cluster, we want to find two clusters, that can be more or less extended. The goal is to separate the two clusters well enough so that the cal direction is not too bad. It seems to me that this separation is better seen when using the direction of the main event : when projecting the crystals onto the plane perpendicular to the direction, we should end up with two blobs (more or less compact). When using a different axis, the projected cal clusters should be more blurred.
  • The issue is that we don't know the main event direction before performing the track finding, which needs the cal direction as an input.
  • One possible solution is to perform a cal+tkr cluster : find the direction that makes the projected tkr ckuster and cal clusters less blurred. Since the ghost cluster is not related to the track information, the projected ghost cluster is likely more blurred than the main event projected cal cluster. The main event cal cluster is related to the track information, so the projected tkr cluster and the main event projected cal cluster should be on top of each other. So the goal is in fact to find the axis that makes the projected tkr cluster and the related projected cal cluster (which is on top of the projected tkr cluster) less blurred.
  • After the axis is found, it can be used to refine the main event cal cluster. Then, the cal direction can be computed and sent to the track finder.
  • Another possibility is to use the found axis to perform the track finding, without using the cal direction.

Some comments from Luca L

I started looking at some events from Philippe's skim (i.e. those PT that make the overlaid gamma to fail the rejection cuts), which Leon put in users/lsrea/overlay4/MC/.

I basically confirm Philippe's comments for the PT evts that are clearly bound to kill an overlaid gamma:

  • many have lots of activity in the CAL, in some cases with very large clusters extending to several modules
  • several have ACD tiles corresponding to tracks
  • a good number have only TKR activity, unrelated to CAL activity

But I also noticed quite some evts which apparently have no visible signal at all in the ED, and the only non-zero quantity in the merit is from some ACD tile; it is hard to believe that these will kill a good gamma event. This is a non negligible fraction of the evts, but I cannot make a more quantitative statement right now.
Carmelo warned me that in some cases FRED looses sync between digis and merit when moving back and fwd between evts, so I should recheck this

  • No labels