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

[Richard Jones]

Kei and all,

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?

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 control.in) 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.

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 control.in file, the same event
is generated by Geant3 regardless of history.

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.

-Richard J.



On Sun, Feb 9, 2014 at 11:49 PM, Kei Moriya <kmoriya at indiana.edu> wrote:

>
> To follow up on the discussion at the Data Challenge meeting
> regarding memory usage for bggen jobs, I ran over 10 runs for
> each configuration of EM background level and had the cluster report
> back the maximum vmem used (see attached plot).
>
> Note that the spikes in max vmem happened most frequently for
> standard EM background (the dashed lines are the average for
> each EM background type, but they are influenced strongly by
> the outliers), while the set with high rate and long gate time
> has no large spikes.
>
> The jobs were set up so that for each run, the original thrown hddm
> file was the same for each EM background set. The RNDM variable
> specified in control.in for hdgeant was always the same. 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?
>
> I also monitored the time it took for each job type to finish.
> The results are
> type        time (hrs)
> no EM bg    1 - 1.5
> standard    2 - 3.5
> high rate   5 - 5.5
> long gate   3 - 3.5
> high rate, long gate  10 - 15
>
> Most of the time is being spent on hdgeant. I don't know why
> some jobs take 50% more time than others. The increase in
> processing time is a much larger penalty than the small increase
> we see in the final REST file sizes.
>
> I've also started looking into the number of tracks and track quality,
> and also photon timing information.
>
>         Kei
>
>
>
> _______________________________________________
> 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/356ef627/attachment-0002.html>