<div dir="ltr">Kei and all,<div><br></div><div>On Feb. 9, you asked: Does anybody know if the simulation of the detector hits is done independent of the EM background, or if the EM background offsets the random number sequence for each hit?</div>
<div><br></div><div>I am not sure what you mean by "offsets the random number sequence". Here is how the simulation works with Monte Carlo input events and BGGATE/BGRATE turned on. Each event submitted to Geant for tracking consists of a list of primary vertices. The first one is the one specified by bggen, with an origin inside the GlueX liquid hydrogen target. The remaining N-1 vertices are all beam photons (spectrum determined by BEAM card in <a href="http://control.in">control.in</a>) with an origin several cm upstream of the active collimator in the cave. Most of these N-1 photons hit the primary collimator and are converted there, generating various backgrounds in the cave and the hall. Around 10% of them go down the beam line, through the GlueX target, and down to the photon beam dump. Only about 0.5% of the original N-1 background photons actually interacts in the GlueX target, but there are a lot of them. </div>
<div><br></div><div><font face="arial, sans-serif">The random number sequence that generates the interactions from the primary physics vertex is not the same with and without bg turned on because the N-1 bg photon beam vertices are thrown before tracking starts, and both the random bg vertex generation and the regular Geant tracking use the same random number generator. This could be changed if desired, so that changes to BGRATE and BGGATE would not affect how the primary vertex particles interact in the detector. As it is, events are still deterministic in the sense that starting with the same seed and <a href="http://control.in">control.in</a> file, the same event is generated by Geant3 regardless of history.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div>The start time of vertex 1 is set so that t=0 is the crossing time of that photon bunch through z=65cm, which is the center of the GlueX target. The vertex time of the remaining N-1 bg photons is randomly distributed within the limits given by the BGGATE card. I could discretise this according to the bunch structure of the beam, but right now it is a purely dc beam structure for bg.</div>
<div><br></div><div>-Richard J.</div><div><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Sun, Feb 9, 2014 at 11:49 PM, Kei Moriya <<a href="mailto:kmoriya@indiana.edu">kmoriya@indiana.edu</a>> wrote:<br><blockquote class="gmail_quote">
<br>
To follow up on the discussion at the Data Challenge meeting<br>
regarding memory usage for bggen jobs, I ran over 10 runs for<br>
each configuration of EM background level and had the cluster report<br>
back the maximum vmem used (see attached plot).<br>
<br>
Note that the spikes in max vmem happened most frequently for<br>
standard EM background (the dashed lines are the average for<br>
each EM background type, but they are influenced strongly by<br>
the outliers), while the set with high rate and long gate time<br>
has no large spikes.<br>
<br>
The jobs were set up so that for each run, the original thrown hddm<br>
file was the same for each EM background set. The RNDM variable<br>
specified in <a href="http://control.in">control.in</a> for hdgeant was always the same. Does<br>
anybody know if the simulation of the detector hits is done<br>
independent of the EM background, or if the EM background offsets<br>
the random number sequence for each hit?<br>
<br>
I also monitored the time it took for each job type to finish.<br>
The results are<br>
type time (hrs)<br>
no EM bg 1 - 1.5<br>
standard 2 - 3.5<br>
high rate 5 - 5.5<br>
long gate 3 - 3.5<br>
high rate, long gate 10 - 15<br>
<br>
Most of the time is being spent on hdgeant. I don't know why<br>
some jobs take 50% more time than others. The increase in<br>
processing time is a much larger penalty than the small increase<br>
we see in the final REST file sizes.<br>
<br>
I've also started looking into the number of tracks and track quality,<br>
and also photon timing information.<font color="#888888"><br>
<br>
Kei<br>
<br>
<br>
</font><br>_______________________________________________<br>
Halld-offline mailing list<br>
<a href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a><br></blockquote></div><br></div>