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
>
########################################################################
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
|
