For mock data production, we have been running 0.5 million events/run,
which keeps runs short at about 1 hour. The spaced file (2000 events,
spaced by 250) is 90 MB, the merged file (spaced file merged
event-by-event with beam background) is 1.2 GB, the readout output is 13
MB.
This seems OK to 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 description)
The SVT readout has S/N of ~25, so a typical hit will remain above noise
level for a long time, about 200 ns. This is the minimum amount of time we
need to simulate for pileup. We actually do more - 500 ns - because the
ECal reads out 400 ns of data with each event.
There isn't a document completely describing the pileup simulation. Maybe
the best thing is this talk:
https://confluence.slac.stanford.edu/download/attachments/156536302/mc_status.pdf
On Fri, 3 Oct 2014, [log in to unmask] wrote:
> Dear Sho,
>
> please consider also that the local scratch disks are of a finite size and a
> typical cluster node runs from 16 to 32 jobs at once. So in my example this
> would require from 370 to 740 Gb of local disk space.
>
> As far as background simulations are concerned, probably it could be an
> issue, but how many bunches before and after the event bunch can overlap
> within the readout? Do we really need to simulate entire detector run time or
> one-two bunches around the trigger only?
>
> In fact, I was asking time ago what exactly this "pile-up" does, but I
> haven't got sufficient information. Is there some document or presentation
> describing this step in details?
>
> Best Regards,
> Mikhail.
>
>
>
>
> On 10/03/2014 04:47 PM, Sho Uemura wrote:
>> way to run FilterMCBunches as part of the readout simulation. We could (I
>> think) rewrite FilterMCBunches so that it can run the readout simulation,
>> and it can insert the
>
>
> ########################################################################
> 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
|