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