I changed your steering file to use SinglesTriggerDriver (and fixed a bug in that driver). Before Matt found that driver, I wrote a flag for FADCPrimaryTriggerDriver that made it into a singles trigger. I reverted those changes since they're redundant, but you can bring them back (r2612) if you want them for some reason (for example, if you wanted the summary table at the end - SinglesTriggerDriver has no printouts).
I also reordered the trigger drivers so the tightest trigger goes first. Otherwise a trigger later in the execute list will always be shadowed by the dead time of the looser triggers. With tightest-first ordering, you can assume that the trigger rate of "tight pair" is just what you see, and the true trigger rate of "loose pair" is the sum of the trigger counts from "tight pair" and "loose pair." (Because the singles triggers are prescaled, they don't shadow each other significantly.) But to get real, solid numbers, it would still be better to run each trigger in a separate readout sim run.
You have 100k events, which is 0.2 ms at 2 ns/event. The trigger counts I see (0 tight pairs, ~35 loose pairs, ~2 1/128 prescaled tight singles, ~1 1/256 prescaled loose singles) correspond to 0, 175, 10, and 5 kHz rates.
Things seem to work, as far as I can tell. Let me know if you find any other problems.
On Sat, 28 Mar 2015, Graham, Mathew Thomas wrote:
Hi Holly,
I don?t have answers, but looked into it a bit and found a few things.
1) We need to specify the detector name for the conditions driver to pick up the conditions for the run (I think Jeremy is going to fix this soon).
<driver name="ConditionsDriver" type="org.hps.conditions.ConditionsDriver">
<runNumber>3422</runNumber>
<detectorName>HPS-ECalCommissioning-v3-fieldmap</detectorName>
<freeze>true</freeze>
</driver>
2) Looking at FADCPrimaryTriggerDriver.java, I don?t think it supports 1 cluster triggers?there?s a ?SinglesTriggerDriver.java?, but I?m not sure it?s working. Kyle should chime in.
3) Running just the PairTrigger0 (with the conditions fix shown in 1) I see:
INFO: 100000 events processed in job
Trigger Processing Results
Single-Cluster Cuts
Total Clusters Processed :: 13541
Passed Seed Energy Cut :: 7128
Passed Hit Count Cut :: 4725
Passed Total Energy Cut :: 4021
Cluster Pair Cuts
Total Pairs Processed :: 697
Passed Energy Sum Cut :: 245
Passed Energy Difference Cut :: 185
Passed Energy Slope Cut :: 178
Passed Coplanarity Cut :: 159
Trigger Count :: 159
Trigger Module Cut Values:
Seed Energy Low :: 0.100
Seed Energy High :: 6.600
Cluster Energy Low :: 0.200
Cluster Energy High :: 2.500
Cluster Hit Count :: 2
Pair Energy Sum Low :: 0.000
Pair Energy Sum High :: 2.000
Pair Energy Difference :: 1.200
Pair Energy Slope :: 0.4
Pair Coplanarity :: 90.0
FADCPrimaryTriggerDriver: Trigger count: 159
TestRunTriggeredReconToLcio - wrote 0 events in job; 159 incomplete events in queue.
End of file reached
?so, if I read correctly, it found 159 loose pair triggers but didn?t write them out for some reason. Not sure why?Sho?
Thanks, Matt
On Mar 27, 2015, at 6:13 PM, Holly Vance <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi,
I have several questions/problems that I need more information on to make sure that the readout software is working.
In taking our slic output monte carlo files for 1.92 GeV running (beam background and tridents), we have a steering file that can produce output files for different types of triggers (singles0, singles1, pairs0, pairs1) that have the same settings that were used for events in December:
org.hps.steering.readout.EngineeringRun2014PrescaledTriggers.lcsim
The input file I use is at /work/hallb/hps/holly/debug/egsv3-triv2-g4v1_s2d6_1.slcio
If I run the steering, I observe several things:
1. The number of pairs being looked at is significantly small (on the order of 2/100k events). Does this make sense? The number of singles being considered was around 7k. So is everything else just background?
2. In the terminal screen shot below, I commented out the other FADC trigger drivers and only ran singles0. The output file is at : /work/hallb/hps/holly/debug/out.singles0.slcio
The corresponding log file is out.triggers.singles0
It only outputs two events that have passed trigger cuts despite my specifying a singles only cut. I am not sure why only 2 events were passed to the pairs trigger cut. I would think there should be more pairs considered. Is there a bug in the FADCPrimaryTriggerDriver? The defaults for pairs looks wide enough for singles, but it somehow only sees a few for consideration. Somehow, specifying a singles cut is still losing out when it is considered for pairs.
3. For events that don't pass cuts, empty slcio files are produced. Basically if I run the steering over the input file as it is, I get one good output file that is from pairs0.
I guess I would like some input from those who produce the monte carlo that this makes sense as well as those who wrote the trigger drivers. I don't understand these results.
Thanks,
Holly
________________________________
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
<Screen Shot 2015-03-27 at 5.32.49 PM.png>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1