[Halld-offline] {SPAM?} memory usage for bggen events

[Richard Jones]

Justin,

You wrote:

In the other experiment I'm involved with (STAR) this superposition is done
with background events from data (once it's available), so the
superposition is done by combining raw hits for the physics event from
Geant and raw hits for the background event from data.  Is there something
about the GlueX simulation which requires that "the superposition must be
carried out at the hits accumulation level inside Geant before hits
aggregation"?  I was (maybe naively) assuming the mechanism that would be
developed for this in GlueX would occur outside of Geant for superimposing
with data as well.  I'm not suggesting we wait for this for DC 2, just
trying to understand the issue.

The superposition of hits after the aggregation phase is an approximation,
which is fine at low rate and low occupation, but not at high
rate/occupation.  The reason is that you can get two hits in the same
counter at the same time, and these two not get properly piled up if you
simply allow both hits to appear in the hit list.  Consider the BCal.
 Right now we are passing a raw digitized wave train from HDGeant to
mcsmear, if I understand what David has done.  With post-aggregation
superposition this would result in several independent pulse trains coming
in the same event from the same physical channel.  Summing the pulse trains
before analyzing them into a hits sequence is what I mean by aggregation.

This difference might not be important for some physics, but especially for
low-rate processes it can be very important in setting the leakage rate for
a given set of cuts.

-Richard J.


On Mon, Feb 10, 2014 at 7:08 AM, Justin Stevens <jrsteven at mit.edu> wrote:

> Hi Richard, All,
>
> On Feb 10, 2014, at 6:01 AM, Richard Jones wrote:
>
> > I cannot think of any study that is going to fail because we generated a
> factor 2-3 fewer events, but there are plenty of things that can go wrong
> if we fail to simulate realistic backgrounds in the detector.  I see no
> advantage to generating even a part of the DC sample with less than 10^7
> g/s background rates and the full 1us gate.
>
> I completely agree that we have to face the background issue head-on, but
> it seems to me that a sub-sample without background could still be useful
> for a comparison.  We have some understanding of the event selection
> techniques that have been developed so far without background, and being
> able to connect with those using the updated tracking, etc. in the software
> since DC 1 would be useful in my opinion.  Also being able to compare an
> analysis done on MC with and without background may provide some insight
> into what features of the background are the most problematic and how to
> reduce those effects in the analysis.
>
> > With more time and effort, we could probably come up with a way to
> generate a library of background events and overlay random entries from the
> library onto the bggen events at the desired rate.  This is not trivial to
> do because the superposition must be carried out at the hits accumulation
> level inside Geant before hits aggregation, but given the computing cost it
> is likely the way to go.
>
> In the other experiment I'm involved with (STAR) this superposition is
> done with background events from data (once it's available), so the
> superposition is done by combining raw hits for the physics event from
> Geant and raw hits for the background event from data.  Is there something
> about the GlueX simulation which requires that "the superposition must be
> carried out at the hits accumulation level inside Geant before hits
> aggregation"?  I was (maybe naively) assuming the mechanism that would be
> developed for this in GlueX would occur outside of Geant for superimposing
> with data as well.  I'm not suggesting we wait for this for DC 2, just
> trying to understand the issue.
>
> Thanks,
> Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20140210/83d527f2/attachment-0002.html>