To be clear, there is only one FilterMCBunches command. We are using the same tool, but probably not in quite the same way: You are taking a signal SLIC output file of 888 MB (I would guess ~180k events), adding some number of empty events after each event to get a 26 GB file (probably ~50 milion events), then running that through the readout simulation. You are not using beam background at any point; for that you would need to use a separate SLIC output file containing beam background. I take a 61 MB signal file (tritrig.slcio) of 12000 events; this is a "trigger tridents" SLIC output file as described in the Confluence page (linked below). I use command-line arguments to FilterMCBunches to tell it to accept only events leaving 100 MeV in both halves of the ECal (this filter accepts roughly 19% of the trigger trident events), stop after it accepts 2000 events, and space events by 250 (add 249 empty events after each event). This is the actual command that does that: java -cp ${hps-java} org.hps.users.meeg.FilterMCBunches -e250 tritrig.slcio tritrig_filt.slcio -d -E0.1 -w2000 The output of this command (tritrig_filt.slcio) is 0.5 million events, 90 MB. Then I merge this file, event-by-event, with a 0.5 million event file of beam background, 1.2 GB. The output of the merge is 1.2 GB. https://confluence.slac.stanford.edu/display/hpsg/Finding+Monte+Carlo+data+at+JLab ECal readout window: I don't know what FADC settings are being used for the new run, but in the test run the FADCs were set to read out and search for pulses in a 400 ns window of the readout pipeline. As you note, this is much longer than the pulse width, but there is a separate setting that determines how much of each pulse is integrated. So it is good for the readout window to be significantly wider than the integration window. SVT readout: For each event, the SVT reads out 6 samples with a 24 ns (not 25 ns) spacing. This is the same for every sensor and channel, though channels without hits are not saved in the data. So the readout covers a time of 6*24=144 ns. On Mon, 6 Oct 2014, [log in to unmask] wrote: > Hi Sho, > > sorry, I am not sure to understand: you have signal StdHep file of half > million events of 90 Mb, then 1.2 Gb is the file merged with beam background? > I though your "FilterMCBunches" does something similar, but apparently from a > similar signal file I get 26 Gb of "merged" (probably included empty bunches > only, and hopefully some detector noise?) events. > > Ether the simulated beam background appears only in 5% of beam bunches or > "FilterMCBunches" does something completely different. > > Why ECal reads 400 ns of data? I though shaping time was ~30 ns? One could > expect ~100 ns of sampling. > > Best Regards, > Mikhail. > > > > > On 10/03/2014 05:50 PM, Sho Uemura wrote: >> me, and I think (for the reasons I gave earlier) that for production MC the >> size of the spaced file is never significant relative to the other >> resources (the beam background file, CPU). For user work that is (as you've >> seen) not always the case, but I still think that this can be mitigated >> with better use of the filter tools built in to FilterMCBunches. (if you >> run FilterMCBunches with a -e argument but nothing else, it will print a >> des > > ######################################################################## 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