Guide to Monte Carlo event timing and detached vertices in HDGeant/4

From GlueXWiki
Revision as of 20:21, 20 July 2018 by Jonesrt (Talk | contribs) (Conceptual overview)

Jump to: navigation, search

Photon beam timing visualization.png

Conceptual overview

Event vertex timing in the hdgeant/hdgeant4 simulation is illustrated in the figure above. The blue lines represent the planar wavefronts of the photon beam pulse structure, and the gray box represents the liquid hydrogen target. The target mid-plane at z=65cm has been defined as the simulation clock reference plane, so that the clock ticks every time a photon pulse passes through that plane. That is all you are allowed to know about the t=0 of the simulation clock. In the real experiment, you do not know a proiri which pulse contained the gamma that generated the interaction, all you know is that it was one of this discrete set within some dozen or so of the bunch that the event trigger time points to. After track vertexing, you can figure that out, but from the clock alone you cannot know anything more than this. Thus, the simulation is designed to obscure the true reference time of the interaction vertex, so that you have to work it out in the reconstruction and analysis in just the same way.

Of course, the obscuring of truth information in the simulation is not complete. If you want to cheat, you can inspect the Monte Carlo record in each simulated event and find out what the exact time was of the primary interaction vertex. Below I give an example of an event from an external Monte Carlo event generator that has been prepared for input to hdgeant/hdgeant4. This particular event might represent a heavy photon produced in the target and decaying to e+e- some distance from the primary vertex. The units of distance are cm, time is ns, and momentum/energy are GeV.

<HDDM class="s" version="1.0" xmlns="http://www.gluex.org/hddm">
  <geometry md5reconstruction="" md5simulation="" md5smear="" />
  <physicsEvent eventNo="1" runNo="42553">
    <reaction type="0" weight="0">
      <beam type="Photon">
        <momentum E="0.0143928" px="-5.79431e-08" py="1.6068e-07" pz="0.0143928" />
        <polarization Px="0.0477761" Py="-0.062995" Pz="8.95607e-07" />
      </beam>
      <vertex>
        <product decayVertex="0" id="1" mech="0" parentid="0" pdgtype="0" type="Unknown">
          <momentum E="11.6002" px="-0.00026237" py="-6.82093e-05" pz="11.6002" />
        </product>
        <origin t="0" vx="0" vy="0" vz="0" />
      </vertex>
      <vertex>
        <product decayVertex="1" id="2" mech="1447972675" parentid="1" pdgtype="-11" type="Positron">
          <momentum E="0.00367671" px="-0.000451987" py="-0.000230665" pz="0.0036055" />
        </product>
        <product decayVertex="1" id="3" mech="1447972675" parentid="1" pdgtype="11" type="Electron">
          <momentum E="0.0107161" px="0.000553506" py="-0.00110481" pz="0.0106324" />
        </product>
        <origin t="1.01" vx="-0.582" vy="0.004" vz="8.776" />
      </vertex>
      <random seed1="1078571841" seed2="1576092742" seed3="709975946" seed4="912931182" />
    </reaction>
  </physicsEvent>
</HDDM>

 

The primary vertex is always the one with decayVertex="0", which should be the first one in the vertex tag sequence. The meaning of most of the generated event structure above should be more or less obvious. Here we focus on the <origin> tags, where all of the information about event timing is located. The primary vertex in this example is given an origin with zero time and zero position. This is the origin in time and space for the generated input event, which should normally be set to zero for the primary vertex. For secondary vertices, the ones with decayVertex>0, the origin times and positions represent offsets in time and space relative from the primary vertex. By setting the primary vertex position and time to 0, you are telling hdgeant/hdgeant4 to randomize the physical origin for the event within the beam-target overlap volume, then set the t=0 for the event such that it corresponds to one of the ticks of the beam clock. The simulation takes care of making sure that the time and space origins of the primary vertex coincides with one of the photon wavefronts. Using this clock, the peaks in the tagger time distribution always appear at multiples of the beam clock period.

This scheme may seem unnecessarily complicated, compared to a simple scenario where the time from the primary vertex origin just gets copied into the simulation clock. Doing that, however, would mean that the tagging coincidences would not work correctly. Tagging requires that the vertex z and the vertex t must be linearly related to each other, modulo 4 ns.