Difference between revisions of "How HDGeant defines time-zero for physics events"

From GlueXWiki
Jump to: navigation, search
(How?)
 
(9 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
====How?====
 
====How?====
  
Case 1 above is covered in
+
In Geant3 the clock that maintains the current time during tracking is the variable TOFG in common block /GCTRAK/.  When the user code calls GSVERT followed by GSKINE for each of the final-state particles to be simulated for a given event, each particle is pushed onto the tracking stack together with a copy of the value that was in TOFG at the time GSVERT/GSKINE was called.  Thereafter as the simulation proceeds for each track, its clock advances from the start time that was initialized when the event was declared.  Most users assume that it starts from zero, but it is better to explicitly set it.  The computation of the value of TOFG at event startup is centralized in a single-line fortran function called settofg(vertex,t0), which has the following header.
 +
 
 +
<pre>
 +
      subroutine settofg(vertex,time0)
 +
      real vertex(3)        ! cm
 +
      real time0            ! ns
 +
*
 +
* Sets the Geant variable TOFG which determines the start time of the
 +
* tracking for subsequent particles placed on the primary stack.  The
 +
* start time is determined assuming a beam photon is being generated.
 +
* It is set so that the photon will cross the reference time plane at
 +
* TOF=t0 if it makes it that far.
 +
</pre>
 +
 
 +
The first argument gives the position of the photon interaction that produces the event, so that the time offset can be computed to its passage through the target midplane.  Only the third component is used at present, but it is a 3-vector because an argument of this type is needed for the call to GSVERT that is needed anyway to initialize the event.  The second argument is there to provide an additional time offset, in case the interacting photon is from a different beam bucket than the one that generated the trigger for the event.  Most of the time the call is made with time0=0.  For a description of an exception, see the next section.  The formula used by settofg is
 +
<pre>
 +
      TOFG=2*int(time0/beam_bucket_period_ns+0.5)*1e-9
 +
    +    +(vertex(3)-reference_time_plane_z)/CLIGHT
 +
</pre>
 +
where the meaning of parameters ''beam_bucket_period_ns'', ''reference_time_plane_z'' and ''CLIGHT'' are self-evident.  Note that this formula assumes that the photon beam is sufficiently colinear with the z axis that corrections from off-axis velocity components of the beam photon are negligible.
  
 
====Where?====
 
====Where?====
 +
 +
For case 1 above, the call to settofg appears right before the call to GSVERT in beamgen.F around line 211.  The comment at the top of the file clarifies how t0 is defined.
 +
<pre>
 +
* ...    The photon begins its lifetime just upstream of
 +
* the primary collimator (WARNING: position hard-wired in the code below)
 +
* and is tracked by the simulation from there forward, but its time t0
 +
* identifies its beam bucket, ie. the time the photon would reach the time-
 +
* reference plane at the middle of the target.  Beam bucket t0=0 is the
 +
* one that generates the event and defines the time origin for all hit times.
 +
</pre>
 +
 +
For case 2 above, the call to settofg appears right before the call to GSVERT in hddmInput.c around line 176.  Note that this is c code calling fortran, so the appearance of the call is a bit different, but the usage is the same.  The Usage Notes comment at the header of the source file clarifies how t0 is defined.
 +
 +
<pre>
 +
* 2)  The start time for the event in HDGeant is defined to be the
 +
*      instant the beam photon passes through the midplane of the target,
 +
*      or would have passed through the midplane if it had gotten that far.
 +
</pre>
  
 
====Why?====
 
====Why?====
 +
 +
It is done this way because the time of the interaction is not an accessible quantity in this experiment, nor is it a useful thing to produce as an intermediate result (eg. to compute time-of-flight) in the analysis of an event.  The accelerator clock provides a strobe which, with an appropriate offset, can precisely identify the instant that the photon bunch reaches the center of the target.  Using the start counter, one can expect to identify with reasonable assurance which beam bucket produced a given recoil proton track. Rather than provide an additional variable in the Monte Carlo event to mark the accelerator clock strobe, I decided to simply reference all times in the output event to that clock.
 +
 +
If anyone for some perverse reason wants to get the interaction time of the physical vertex, he can compute it by subtracting ''(vertex[2]-reference_time_plane_z)/CLIGHT'' from the recorded times, where the ''vertex'' array is stored in the Monte Carlo section of the hddm output event from HDGeant, ''reference_time_plane_z'' is 65 cm, and ''CLIGHT'' is approximately 30 cm/ns.

Latest revision as of 15:43, 7 June 2010

Normally Geant simulations produce hit times that are referenced to the instant of the interaction in the target. This is not the case for HDGeant, whenever there is an incident photon present or implied) for the event. The only exception to this rule is the trivial case of the particle gun, where the user specifies the location of the starting point for the single-track vertex via the SCAP input card, and the time the particle emerges from the gun is defined to be zero. The other two cases to consider are:

  1. the internal coherent bremsstrahlung beam generator: time0 is defined as the instant the beam photon being simulated passes through the midplane of the GlueX target, or would have if it had not interacted upstream of that plane.
  2. events generated by an external Monte Carlo generator (eg. pythia, genr8): time0 is defined as the instant that the (implied) beam photon, whose interaction produced the MonteCarlo-specified final state, passed through the midplane of the GlueX target, or would have if it had lived that long.

That is the executive summary. If you only need to know the answer to what questions, then you have read far enough. If you want to know how, where, and (above all) why this behavior, then read on.

How?

In Geant3 the clock that maintains the current time during tracking is the variable TOFG in common block /GCTRAK/. When the user code calls GSVERT followed by GSKINE for each of the final-state particles to be simulated for a given event, each particle is pushed onto the tracking stack together with a copy of the value that was in TOFG at the time GSVERT/GSKINE was called. Thereafter as the simulation proceeds for each track, its clock advances from the start time that was initialized when the event was declared. Most users assume that it starts from zero, but it is better to explicitly set it. The computation of the value of TOFG at event startup is centralized in a single-line fortran function called settofg(vertex,t0), which has the following header.

      subroutine settofg(vertex,time0)
      real vertex(3)        ! cm
      real time0            ! ns
*
* Sets the Geant variable TOFG which determines the start time of the
* tracking for subsequent particles placed on the primary stack.  The
* start time is determined assuming a beam photon is being generated.
* It is set so that the photon will cross the reference time plane at
* TOF=t0 if it makes it that far.

The first argument gives the position of the photon interaction that produces the event, so that the time offset can be computed to its passage through the target midplane. Only the third component is used at present, but it is a 3-vector because an argument of this type is needed for the call to GSVERT that is needed anyway to initialize the event. The second argument is there to provide an additional time offset, in case the interacting photon is from a different beam bucket than the one that generated the trigger for the event. Most of the time the call is made with time0=0. For a description of an exception, see the next section. The formula used by settofg is

      TOFG=2*int(time0/beam_bucket_period_ns+0.5)*1e-9
     +    +(vertex(3)-reference_time_plane_z)/CLIGHT

where the meaning of parameters beam_bucket_period_ns, reference_time_plane_z and CLIGHT are self-evident. Note that this formula assumes that the photon beam is sufficiently colinear with the z axis that corrections from off-axis velocity components of the beam photon are negligible.

Where?

For case 1 above, the call to settofg appears right before the call to GSVERT in beamgen.F around line 211. The comment at the top of the file clarifies how t0 is defined.

* ...     The photon begins its lifetime just upstream of
* the primary collimator (WARNING: position hard-wired in the code below)
* and is tracked by the simulation from there forward, but its time t0
* identifies its beam bucket, ie. the time the photon would reach the time-
* reference plane at the middle of the target.  Beam bucket t0=0 is the
* one that generates the event and defines the time origin for all hit times.

For case 2 above, the call to settofg appears right before the call to GSVERT in hddmInput.c around line 176. Note that this is c code calling fortran, so the appearance of the call is a bit different, but the usage is the same. The Usage Notes comment at the header of the source file clarifies how t0 is defined.

 * 2)   The start time for the event in HDGeant is defined to be the
 *      instant the beam photon passes through the midplane of the target,
 *      or would have passed through the midplane if it had gotten that far.

Why?

It is done this way because the time of the interaction is not an accessible quantity in this experiment, nor is it a useful thing to produce as an intermediate result (eg. to compute time-of-flight) in the analysis of an event. The accelerator clock provides a strobe which, with an appropriate offset, can precisely identify the instant that the photon bunch reaches the center of the target. Using the start counter, one can expect to identify with reasonable assurance which beam bucket produced a given recoil proton track. Rather than provide an additional variable in the Monte Carlo event to mark the accelerator clock strobe, I decided to simply reference all times in the output event to that clock.

If anyone for some perverse reason wants to get the interaction time of the physical vertex, he can compute it by subtracting (vertex[2]-reference_time_plane_z)/CLIGHT from the recorded times, where the vertex array is stored in the Monte Carlo section of the hddm output event from HDGeant, reference_time_plane_z is 65 cm, and CLIGHT is approximately 30 cm/ns.