Difference between revisions of "Guide to Monte Carlo event timing and detached vertices in HDGeant/4"

From GlueXWiki
Jump to: navigation, search
(Conceptual overview)
Line 37: Line 37:
 
  </nowiki>
 
  </nowiki>
  
The primary vertex is always the one with decayVertex="0", which should be the first one in the vertex tag sequence. The meaning 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 position. This is normally the location of the primary vertex within the target volume, but if you set all three components to zero then a random position will be generated within the beam-target overlap volume, and the entire event shifted to place the origin there. There must always be one primary vertex per physics event. If there are secondary vertices that need to be specified by the Monte Carlo generator, give these decayVertex>0, as in the example above, and specify in the origin tag the time and position of the detached vertex relative from the primary vertex. In the above example, the Unknown particle travels a distance 8.8cm downstream from the primary vertex, where it decays into e+,e- after 1.01 ns. When the primary vertex is randomized inside the beam-target interaction volume, all vertices are shifted by the same amount.
+
The primary vertex is always the one with decayVertex="0", which should be the first one in the vertex tag sequence. The meaning 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 vertexing and timing is located.
  
 +
====the vertex position====
 +
The primary vertex in this example is given an origin with zero position. This is normally the location of the primary vertex within the target volume, but if you set all three components to zero then a random position will be generated by hdgeant/hdgeant4 within the beam-target overlap volume, and the entire event shifted to place the origin there. There must always be one primary vertex per physics event. If there are secondary vertices that need to be specified by the Monte Carlo generator, give these decayVertex>0, as in the example above, and specify in their origin tag the time and position of the detached vertex relative to the primary vertex. In the above example, the Unknown particle travels a distance 8.8cm downstream from the primary vertex, where it decays into e+,e- after 1.01 ns. When the primary vertex is randomized inside the beam-target interaction volume, all vertices are shifted by the same amount.
 +
 +
===the vertex time====
 
The interpretation of the t attribute of the origin tag is a bit more complicated. The meaning is different in the input record that is fed to hdgeant/hdgeant4 from an external event generator, and the value that the same attribute contains when the hits events is written to the simulation output. The most important thing to understand in this context is how the simulation clock is synchronized with the beam: t=0 in the simulation corresponds to one of the photon wavefronts in the beam passing through the reference plane at z=65cm. This means that if the primary vertex were at 95cm (would be outside the target!) then the vertex time would be 1ns, or 5ns, or 17ns, or -11ns. Which one of these is chosen is randomized for each event in the simulation to mimic the time uncertainty in the real event trigger. This complication would be a lot to ask of event generators, which should focus exclusively on the internal event topology. Because of this, the above vertex time is added to the origin t attribute in the input event record before it is fed to the hdgeant/hdgeant4 simulation. Thus, if you specify t=0 in the input event primary vertex origin, as in the above example, this will be added to the vertex position-dependent time offset described above before it is fed to the simulation. When the same event is written out with all of the simulated hits, the t value in the origin tags of the vertices are all reported with the corrected values that were actually fed to the simulation. This makes it possible to directly compare truth hits times with the vertex time in the simulation output and know that one is working with just one unique simulation clock.
 
The interpretation of the t attribute of the origin tag is a bit more complicated. The meaning is different in the input record that is fed to hdgeant/hdgeant4 from an external event generator, and the value that the same attribute contains when the hits events is written to the simulation output. The most important thing to understand in this context is how the simulation clock is synchronized with the beam: t=0 in the simulation corresponds to one of the photon wavefronts in the beam passing through the reference plane at z=65cm. This means that if the primary vertex were at 95cm (would be outside the target!) then the vertex time would be 1ns, or 5ns, or 17ns, or -11ns. Which one of these is chosen is randomized for each event in the simulation to mimic the time uncertainty in the real event trigger. This complication would be a lot to ask of event generators, which should focus exclusively on the internal event topology. Because of this, the above vertex time is added to the origin t attribute in the input event record before it is fed to the hdgeant/hdgeant4 simulation. Thus, if you specify t=0 in the input event primary vertex origin, as in the above example, this will be added to the vertex position-dependent time offset described above before it is fed to the simulation. When the same event is written out with all of the simulated hits, the t value in the origin tags of the vertices are all reported with the corrected values that were actually fed to the simulation. This makes it possible to directly compare truth hits times with the vertex time in the simulation output and know that one is working with just one unique simulation clock.
  
Line 73: Line 77:
  
 
  </nowiki>
 
  </nowiki>
 +
 +
====special considerations with delayed vertices====

Revision as of 22:19, 20 July 2018

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 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 vertexing and timing is located.

the vertex position

The primary vertex in this example is given an origin with zero position. This is normally the location of the primary vertex within the target volume, but if you set all three components to zero then a random position will be generated by hdgeant/hdgeant4 within the beam-target overlap volume, and the entire event shifted to place the origin there. There must always be one primary vertex per physics event. If there are secondary vertices that need to be specified by the Monte Carlo generator, give these decayVertex>0, as in the example above, and specify in their origin tag the time and position of the detached vertex relative to the primary vertex. In the above example, the Unknown particle travels a distance 8.8cm downstream from the primary vertex, where it decays into e+,e- after 1.01 ns. When the primary vertex is randomized inside the beam-target interaction volume, all vertices are shifted by the same amount.

the vertex time=

The interpretation of the t attribute of the origin tag is a bit more complicated. The meaning is different in the input record that is fed to hdgeant/hdgeant4 from an external event generator, and the value that the same attribute contains when the hits events is written to the simulation output. The most important thing to understand in this context is how the simulation clock is synchronized with the beam: t=0 in the simulation corresponds to one of the photon wavefronts in the beam passing through the reference plane at z=65cm. This means that if the primary vertex were at 95cm (would be outside the target!) then the vertex time would be 1ns, or 5ns, or 17ns, or -11ns. Which one of these is chosen is randomized for each event in the simulation to mimic the time uncertainty in the real event trigger. This complication would be a lot to ask of event generators, which should focus exclusively on the internal event topology. Because of this, the above vertex time is added to the origin t attribute in the input event record before it is fed to the hdgeant/hdgeant4 simulation. Thus, if you specify t=0 in the input event primary vertex origin, as in the above example, this will be added to the vertex position-dependent time offset described above before it is fed to the simulation. When the same event is written out with all of the simulated hits, the t value in the origin tags of the vertices are all reported with the corrected values that were actually fed to the simulation. This makes it possible to directly compare truth hits times with the vertex time in the simulation output and know that one is working with just one unique simulation clock.

So in the input record from the external generator, t=0 means that the vertex time is exactly aligned with the time of one of the photon wavefronts, wherever the interaction occurs in the target. If you give t="1.5" in the input record, the interaction will occur 1.5ns after the last photon wavefront passed over that spot. There may be some scenario where that makes sense, but generally that is unphysical. Setting t=0 in the primary vertex is almost always the correct thing to do in your event generator. To see where that ends up on the simulation clock, run it through hdgeant/hdgeant4 and look at the origin t-value in the output MC record from the simulation. Below is what the above example event record looks like after running it through hdgeant4. Notice that only the <origin> tag has changed between the above printout and the one below. The hitView section has been suppressed in this printout.

<HDDM class="s" version="1.0" xmlns="http://www.gluex.org/hddm">
  <geometry md5reconstruction="" md5simulation="eb0f31e2970cfcd67a51371a6dbf2216" 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="-12.2361" vx="-0.130076" vy="0.185582" vz="58.0447" />
      </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="-11.2461" vx="0.869924" vy="1.18558" vz="59.0447" />
      </vertex>
      <random seed1="1078571841" seed2="1576092742" seed3="709975946" seed4="912931182" />
    </reaction>
  </physicsEvent>
</HDDM>

 

special considerations with delayed vertices