<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think the big challenge now is to get the crashes under control. Given that we were all convinced that this was the <div>case two weeks ago,hopefully it is relatively quick. We should then run with what we have for the EM backgrounds.</div><div>This is not our last data challenge, and learning how to deal with the EM rate is very important.</div><div><br></div><div>We can also start a discussion (for future challenges) on how to improve the overall efficiency of doing the EM</div><div>backgrounds.</div><div><br></div><div> Curtis <br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>---------</div><div>Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre; "> </span>MCS Associate Dean for Faculty and Graduate Affairs</div><div>Wean: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre; "> </span>Professor of Physics</div><div>Doherty: (412) 268-3090<span class="Apple-tab-span" style="white-space: pre; "> </span>Carnegie Mellon University</div><div>Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre; "> </span>Pittsburgh, PA 15213</div><div><a href="mailto:curtis.meyer@cmu.edu">curtis.meyer@cmu.edu</a><span class="Apple-tab-span" style="white-space: pre; "> </span>http://www.curtismeyer.com/</div></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Feb 10, 2014, at 8:53 AM, Eugene Chudakov <<a href="mailto:gen@jlab.org">gen@jlab.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">The EM background events are special, since only a small fraction of<br>them make hits in the detectors. Potentially, one may consider<br>generating these events separately and either writing down the<br>appropriate seeds for the random number generators or just the hit<br>information (before the digitization). People have been doing this<br>during the 40 years of the history of GEANT.<br><br>However, at the moment we should use whatever exists and try to make<br>sense of the results. A factor of 2-3 in statistics is unimportant, as<br>Richard already mentioned. The next important step will be a<br>comparison of the MC results with the real data when it appears.<br><br>Regards,<br>Eugene<br><br>On Mon, 10 Feb 2014, David Lawrence wrote:<br><br><blockquote type="cite"><br>Hi All,<br><br> 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).<br><br> 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.<br><br><br>Regards,<br>-David<br><br><br><br>Usage:<br> hddm_merge_events [-Mmaxevents] [-oOutputfile] [-l|s -Nnum] file1.hddm [-l|s -Nnum] file2.hddm ...<br><br>options:<br> -oOutputfile Set output filename (def. merged.hddm)<br> -Mmaxevents Do not write out more than maxevents events<br> -Nnum Merge together num events from each of the following input files<br> -l Continually loop over events from the following inputs<br> -s Stop when all events from the following inputs have been read<br><br>This will take events from 1 or more HDDM files and merge them<br>into events written to an output HDDM file. This works by simply<br>copying the s_PhysicsEvent objects into a single event that gets<br>written to the output file.<br><br>Multiple input files can be specified and for each, the number of<br>events to merge. This allows one to do things such as merge 3 events<br>from a file of background events with a single event from a file of<br>signal events to get a sample of events with 3 times the backaground<br>rate overlayed on the signal.<br><br>By specifying the -l flag, certain input sources can be looped over<br>to recycle thier events. This is useful if one has a sample of<br>background events that is smaller than the sample of signal events.<br>See the examples below.<br><br>NOTE: Events are not merged such that double hits are<br>merged. Hits are only copied so it is possible for<br>the output event to have two hits on the same wire<br>at the same time.<br><br>Example 1:<br> hddm_merge_events -N2 file.hddm<br><br> This will combine every 2 events from file.hddm into a single in the<br>output. Since no output file name is specified, the file "merged.hddm"<br>will be used.<br><br><br>Example 2:<br> hddm_merge_events signal.hddm -N10 em_bkgnd.hddm -N1 hadronic_bkgnd.hddm<br><br>This will combine 1 event from signal.hddm, 10 events from em_bkgnd.hddm,<br>and 1 event from hadronic_bkgnd.hdm into a single output event.<br><br><br>Example 3:<br> hddm_merge_events -N3 file1.hddm file2.hddm file3.hddm -N1 file4.hddm<br><br>This will combine 3 events from each of file1.hddm, file2.hddm, and<br>file3.hddm with 1 event from file4.hddm.<br><br><br>Example 4:<br> hddm_merge_events signal.hddm -l -N10 background.hddm<br><br>This will combine 1 signal event with 10 background events to create<br>and output event. The events in the background file will be looped<br>over continuosly as needed until all of the signal events have been<br>processed.<br><br><br><br><br>On Feb 10, 2014, at 7:08 AM, Justin Stevens <<a href="mailto:jrsteven@mit.edu">jrsteven@mit.edu</a>> wrote:<br><br><blockquote type="cite">Hi Richard, All,<br><br>On Feb 10, 2014, at 6:01 AM, Richard Jones wrote:<br><br><blockquote type="cite">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.<br></blockquote><br>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.<br><br><blockquote type="cite">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.<br></blockquote><br>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.<br><br>Thanks,<br>Justin<br>_______________________________________________<br>Halld-offline mailing list<br><a href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-offline<br></blockquote><br></blockquote>_______________________________________________<br>Halld-offline mailing list<br><a href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-offline</blockquote></div><br></div></body></html>