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

[David Lawrence]

Hi All,

  I just want to point out that there already exists a program to combine signal and background events as Justin describes, outside of GEANT. This was designed to be used with a library of backgrounds events as Richard suggested. The problem with this method is that it can lead to multiple detector hits on the same channel that overlap in time in a way the electronics would never produce. I believe this was the reason Richard said we need to merge them at the accumulation level (correct me if I’m wrong).

  One could modify hddm_merge_events to combine hits close in time, but it wouldn’t be the same and would take a little work. Since it sounds like the hit due to EM is not all that bad (factor of 2, not a factor of 10) I would be inclined to agree with Richard that we should bite this bullet and just include the EM background in the original simulation. That’s just my 2 cents though.


Regards,
-David



Usage:
     hddm_merge_events [-Mmaxevents] [-oOutputfile] [-l|s -Nnum] file1.hddm [-l|s -Nnum] file2.hddm ...

options:
    -oOutputfile  Set output filename (def. merged.hddm)
    -Mmaxevents   Do not write out more than maxevents events
    -Nnum         Merge together num events from each of the following input files
    -l            Continually loop over events from the following inputs
    -s            Stop when all events from the following inputs have been read

 This will take events from 1 or more HDDM files and merge them
 into events written to an output HDDM file. This works by simply
 copying the s_PhysicsEvent objects into a single event that gets
 written to the output file.
 
 Multiple input files can be specified and for each, the number of
 events to merge. This allows one to do things such as merge 3 events
 from a file of background events with a single event from a file of
 signal events to get a sample of events with 3 times the backaground
 rate overlayed on the signal.
 
 By specifying the -l flag, certain input sources can be looped over
 to recycle thier events. This is useful if one has a sample of
 background events that is smaller than the sample of signal events.
 See the examples below.
 
 NOTE: Events are not merged such that double hits are
 merged. Hits are only copied so it is possible for
 the output event to have two hits on the same wire
 at the same time.
 
 Example 1:
     hddm_merge_events -N2 file.hddm
 
  This will combine every 2 events from file.hddm into a single in the
 output. Since no output file name is specified, the file "merged.hddm"
 will be used.
 
 
 Example 2:
     hddm_merge_events signal.hddm -N10 em_bkgnd.hddm -N1 hadronic_bkgnd.hddm
 
 This will combine 1 event from signal.hddm, 10 events from em_bkgnd.hddm,
 and 1 event from hadronic_bkgnd.hdm into a single output event.
 
 
 Example 3:
     hddm_merge_events -N3 file1.hddm file2.hddm file3.hddm -N1 file4.hddm
 
 This will combine 3 events from each of file1.hddm, file2.hddm, and
 file3.hddm with 1 event from file4.hddm.
 
 
 Example 4:
     hddm_merge_events signal.hddm -l -N10 background.hddm
 
 This will combine 1 signal event with 10 background events to create
 and output event. The events in the background file will be looped
 over continuosly as needed until all of the signal events have been
 processed.
 



On 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
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20140210/888831e9/attachment-0002.html>