|
|
| Line 9: |
Line 9: |
|
| |
|
| Ben's first approach to the [[DVCS Cluster finding 8-Oct-2007]]. | | Ben's first approach to the [[DVCS Cluster finding 8-Oct-2007]]. |
|
| |
| Attached are some images of the program that interfaces to the V1495
| |
| module. This let me make a pattern, send it to the V1495, and retrieves
| |
| the processed information from the V1495 that would be used for generating
| |
| the trigger.
| |
| [http://clonweb/wiki/clondocs/DVCS_Trigger/Trigger_Regular.png Trigger_Regular] is the algorithm as described in the specification
| |
| document that I received. It looks at all possible 3x3 windows and
| |
| determines if there are more hit towers than the programmed threshold
| |
| (here the threshold was set to 4 - there had to be more than 4 hits in a
| |
| 3x3 window to define a cluster). As you can see 4 clusters were found in
| |
| the sample image (the cluster count is also reported by the V1495 unit).
| |
| The one in the bottom left has overlapping 3x3 windows that meet the
| |
| cluster definition criteria. In this case, some logic could be used to
| |
| determine that a neighboring cluster has fewer hits than the other
| |
| neighber and so it could supress that report.
| |
| Next, I played around a little more and wrote a simple algorithm that just
| |
| just ran in my program (on my PC, not the V1495) that took the same data
| |
| and caused adjacent hit towers (Up/down/left/right/all diagonals) to
| |
| attract to each other. So if more hits were on the left side of a cluster,
| |
| that cluster value would hop left if the weight was larger than its own
| |
| (or any other direction if the weight were arragned so). I took the same
| |
| data set as in the last image, and ran 3 iterations through this algorithm
| |
| ([http://clonweb/wiki/clondocs/DVCS_Trigger/Trigger_Alg_Step1.png fig1] [http://clonweb/wiki/clondocs/DVCS_Trigger/Trigger_Alg_Step2.png fig2] [http://clonweb/wiki/clondocs/DVCS_Trigger/Trigger_Alg_Step3.png fig3]) and you can see the hits clump together and increase in count when two
| |
| hits go to the same cell. The idea here would be to run this algorithm,
| |
| and then apply a threshold to each cell to determine if it is a cluster or
| |
| not. Anyway, you can see now the bottom left cell clumps together to a
| |
| single point where the "center of mass" would have been for those original
| |
| hits. So does the upper left. The upper right fails to clump into a single
| |
| point because there is not bias to move either way because there is equal
| |
| pull in both directions (this would be something that can be overcome by
| |
| forcing them to always go a particular direction when pulls are equal).
| |
| For the heck of it I sythesized this algorithm on the FPGA and found it
| |
| will need about 3 times the available resources (not really a surprise)!
| |
| This, or something of similar complexity could work if spread over more
| |
| that one board. I've got some ideas for dealing with that if it is of
| |
| interest.
| |
| Determining the X/Y location of the clusters is actually a bit more
| |
| difficult (especially if the latency needs to be kept low). This should be
| |
| feasible, but it will take several more, at least, clock cycles beyond
| |
| when a trigger has been determined. This is because all 424 potential
| |
| clusters will have to be looked at and probably sorted. Just a guess is
| |
| that it could take about 40ns beyond the assertion of the ASYNC trigger.
| |
| If there is any flexibility here it may be of some use. I'll certainly
| |
| find out more when I get around to implementing this feature. Currently,
| |
| I'm planning to focus on "properly" finding clusters.
| |
| I'm interested in seeing what some real data looks like. There's probably
| |
| no need to format it because I can just read it in with some standard file
| |
| I/O in c++.
| |
| I need clarification on how to deal with adjacent cluster hits (whether to
| |
| count them individually or not, or if we need to do further processing).
| |
|
| |
|
| Sergey, Rustam (Oct-9-2007 through Oct-16-2007): | | Sergey, Rustam (Oct-9-2007 through Oct-16-2007): |
Current section contains DVCS Calorimeter Trigger System development materials.
Project in progress
First approach to System Requirements (September 2007) (PowerPoint,
HTML).
Ben's presentation on CLON meeting 3-Oct-2007: preliminary design.
Ben's first approach to the DVCS Cluster finding 8-Oct-2007.
Sergey, Rustam (Oct-9-2007 through Oct-16-2007):
Calibration data: 10000 events ascii file generated from dvcs_047213.A00. Pedestals were used as for the run 46595 with
the beam current=20 nA (presented on this plot).
Calibration data subset: About 3200 events ascii file contains pi0 events only. That file can be considered as a sample
of 'good' events, trigger system should pass all of them.
Production data: 10000 events ascii file generated from clas_047210.A01 using pedestals for run 46595.
ASCII file containing all 'good' events from the same datafile (actually all events from so-called
skim file egg_47210_pass1_a01.bos).
Ben's presentation on CLON meeting 10-Oct-2007: Cluster Finding.
Ben's observations on DVCS data processing 10-Oct-2007.
Ben's preliminary results on DVCS Trigger efficiency studies 11-Oct-2007.
Useful documentation
CAEN V895 Discriminator Manual Revision 2, September 2002, pdf.
CAEN V1495 Logic Unit Manual Revision 4, January 2007, pdf.
V1495-related software downloaded from CAEN site on September 25, 2007 (check CAEN for newer versions !):
Our materials:
