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
