DVCS Trigger System

From CLONWiki
Revision as of 13:39, 16 October 2007 by Boiarino (talk | contribs)
Jump to navigation Jump to search

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. 

   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.
   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
(fig1 fig2 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): 

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:

Retrieved from "https://clonwiki0.jlab.org/wiki/index.php?title=DVCS_Trigger_System&oldid=2648"