Some points:
* (this one mostly for Stepan's benefit) The spaced-out file can be
deleted after readout simulation; there is no need to store it since it
has low information density and it is very fast to generate. So there is
no impact on tape or network disk; it is strictly a load on the local
scratch disk.
* The file size only blows up if you're running a simulation without beam
background, just spaced events. If you're using beam background in
addition to spaced events, the beam background SLIC file will be
significantly larger than the spaced file (since the spaced file has
mostly empty events and the beam background file has stuff in every event,
and the two files need to have the same number of events), as is the file
made by merging those two files, which is what is used in the readout
simulation. So the size of the spaced files is not a problem in production
MC, which is always run with beam background.
* We have a "no pileup" version of the readout simulation that runs
without simulating pileup between consecutive events; this means that you
never need to insert empty bunches. It does not have completely accurate
trigger acceptance, and of course there is no pileup in the detector, but
it is much faster than the regular readout sim. Without knowing what
exactly you're doing, I don't know whether this is appropriate for your
use.
* Specific to your numbers: If the readout simulation output is so much
smaller than the SLIC output, it seems that most of the events in your
StdHep file are not triggering. FilterMCBunches can be used to filter only
events that have a chance of causing triggers (hence the name). This would
reduce the filtered file size.
* There is no easy 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 empty events into the LCSim
event loop. But this would only be useful for no-background simulation.
On Fri, 3 Oct 2014, Stepan Stepanyan wrote:
> Mikhail,
>
> Great point. No we do not have too much disk or tape space,
> in contrary to some believes.
> We had some discussions of even size before, will be good to
> get this resolved and try to be as economical as possible.
>
> Thanks, Stepan
>
> On 10/3/14 9:54 AM, [log in to unmask] wrote:
>> Dear Sirs,
>>
>> is it possible to include "FilterMCBunches" method at the beginning of
>> readout simulation procedure?
>> I have noticed that this step creates huge files, with information density
>> tending to zero.
>>
>> For example I took your StdHep file of - 145 Mb,
>> this produced slic output of - 888 Mb, (already here one
>> could save some bytes)
>> filtering gave - 26 Gb!!!!
>> readout simulation - 1.3 Mb,
>> reconstruction - 2.6 Mb.
>>
>> Is it really necessary to write so much on disk? Do we have too much disk
>> space?
>>
>> Best Regards,
>> Mikhail.
>>
>>
>> ########################################################################
>> 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
>
########################################################################
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
|