trf_proptest: a tool to ensure that similar propagators yield similar results

The proptest binary reads two lists of propagators and surfaces from the input file trf_proptest.input. It also reads the number of "events" to process; each event will consist of a randomly generated track which starts on an ideal cylinder 0.0001 cm from the beampipe. The code generates a random track (with ETrackGenerator) that lies within the specified ETrackGeneratorLimits. The track travels along each of the two paths specified in the input file. The two results comprise a single event in the final ntuple.

Excluding integrated tests, the physical components include:

• ETrackGenerator ( header, source, test )

  Based on and reusing VTrackGenerator, this class randomly generates vectors and errors by drawing from a "flat" distribution between the ETrackGeneratorLimits. The random number generator is whatever VTrackGenerator uses (at the time of this writing, that is trfutil/RandomGenerator = RanluxEngine). Each track is created on a cylinder of radius 0.0001 cm (they have to start somewhere...).

• ETrackGeneratorLimits ( header, source, test )

• PropSurfList ( header, source, test )

  This is a simple double-vector that forces the user to "load" it with a propagator and a surface at the same time. It restricts the construction proceedure to enforce uniformity.

• PropComparator ( header, source, test )

  This class performs all the work. It is constructed with two PropSurfList's. The method computeChi2(ETrack) will propagate the ETrack along both PropSurfLists and return the resulting two final tracks.

• trf_proptest ( header, source, registration header )

  The binary executable of this file handles the input (from a file, using objstream) and the output (to an ntuple, using HepTuple). The "registration header" must be modified by users if they want to test propagators or surfaces that are new to the framework. See below for operating instructions.

trf_proptest currently depends on the following external packages:

• trfbase
• trfutil
• trfxyp
• trfcylplane
• HepTuple

Operating Instructions

1. go into the "bin" directory that holds trf_proptest_registrations.hpp. Edit this file to include headers and calls that will "register" your new objects with objstream. Your new code must make use of registration functions as defined in objstream to use trf_proptest.
2. edit LIBRARIES to include your package(s).
3. remake the package ( cd ../.. ; gmake trf_proptest.bin )
4. continue with the instructions below.

If you want to test only the rudimentary propagators and surfaces that reside in trfcyl, trfdca, etc., or if you have completed the above, simply:

1. Copy trf_proptest.input to your local area and edit it. It contains the number of events to process at the top, followed by two lists of propagators and surfaces. The proptest package can only test objects that can read themselves from objstream.

   Execute trf_proptest (the binary file). It should report that it is making an ntuple with the specified number of events. When it is complete...

   Go into paw and execute the trf_proptest.kumac file. This will make several diagnostic histograms and includes several macros to help you take a look at them.

   The ntuple contains the following words:

   • event     runs from 1 to number demanded in .input file
   • chi2     a measure of agreement between the final tracks. Not really a mathematically rigorous quantity because the tracks are supposed to be the same, but it can still be a measure...
   • code     error codes, not equal to zero if propagation fails

     The following are parameters specific to track 1. Any track has five parameters but they represent different coordinates depending on the surface. Below are listed the parameters for a cylindrical surface; if the user selects a different surface as the final, then the track coordinates will not as labeled below.

   • trk1_0     phi
   • trk1_1     Z in cm
   • trk1_2     alpha = phi direction of track - phi of location
   • trk1_3     tan(lambda) = cot(theta), where theta=ususal polar angle
   • trk1_4     q/p_T, the charge over the p_T
   • dist1     distance from origin to final surface via path 1. This one is not dependent on the details of the final surface.

   • trk2_0     As above, but for the track that propagated along path 2.
   • trk2_1
   • trk2_2
   • trk2_3
   • trk2_4
   • dist2

   
   
   At the tree-level, the tracks should have identical parameters because they start and end in the same place. You should expect small differences if for instance you have different matter effects, which will change error matrices in the case of multiple scattering, or if you have different dE/dx losses.

   ---

   Questions or comments to dladams@fnal.gov or jkrane@fnal.gov

   .