[MINOS @ Indiana University]

Tau Talk

I threw this web page together in a hurry so much of the information may be sketchy, and there might be slight inaccuracies. -Robert Hatcher

The geometry additions

The active detector plane for emusion are defined as "E" planes. Unlike the LST, FLS, and RPC planes, the Emulsion planes are tiled by rectangles rather than divided into long active volume cells.

Each EkPL plane is a rectangular box with width, length, and thickness. They are constructed of an overall material (by default "AIR"). Users can also specify the up- and downstream air gaps between these planes and neighboring passive absorber.

Individual rectangular tiles are set into this plane; for convenience the tiles retain the XT nomenclature. These are constructed out of the material used for the film backing (default "POLY" for polyproylene as a semi-generic plastic). The number of tiles in the plane is the number that will fit without overlap or tuncation in the x and y dimension (only one layer in z). If the fit is not exact, then the extra space is divided equally as a border around the tiles (both between tiles and at the edges).

Into the XT is inserted one or two active CL volumes. The number depends on the value specified for the XT's children. These are made of "EMUL" (emulsion material). Normally they will have the same transverse dimensions as the XT (but are not forced to). They displace the XT material and thus do not add to the z dimension. These volumes simulate surface layers.

Optionally, it is also possible to place a cover layer over the active volume. This inactive CV volume would act as a surface film on top of the CL. Again these displace XT material and do not contribute to the plane's thickness.

Necessary modifications to the neugen interface

The current package uses the Soudan2's NEUGEN to generate the interactions. NEUGEN, by default, immediately decays any tau's using the "tauola" package. The daughter products were then entered into GEANT for tracking. As a result there are two failings with this approach (1) there is *no* offset for the tau vertex (2) even if it were displaced, there would be no connecting hits representing the track of the tau.

I've spent some time working on this problem. There are four possible approaches that I can see off hand:

  1. Ignore (or suppress) the decay generated by NEUGEN/tauola, enter the tau into GEANT to be tracked. Let GEANT generate the decay. This is the least attractive option since GEANT's decay handling scheme is severely limited and probably not acceptable for our purposes.

  2. Ignore/suppress the decay generated by NEUGEN/tauola, enter the tau into GEANT to be tracked. When a decay is signalled by GEANT calling GUDCAY, the tau is passed off to LUND to perform the decay. There was an example of how to do this in the GEANT distribution (but is not called by default). Alas, in careful study I've found major bugs in how this routine was written. The decay products were given the wrong vertex in two ways: (a) they didn't account for the decay point in real space (b) LUND attempts to propagate the tau based on its energy and lifetime which constitutes double counting since GEANT has already handled that. I was in the process of fixing these failing when Adam Para suggested the next method.

    Using LUND is probably not optimal since I'm unsure how realistic it is in doing the decay. I presume it doesn't do polarized taus.

  3. Let NEUGEN/tauola decay the tau. When it comes time to enter the particles into GEANT for tracking, put the tau decay products into "suspended animation" while turning the real tau into a "zombie". The tau gets tracked until the point where the decay occurs, and then the secondaries are revived.

    I'm currently testing my implementation of this scheme. In principle I should also transform the decay products from the original frame to the frame of the tau after energy loss and multiple scattering. These effects are very small so I haven't yet bothered.

  4. Inhibit NEUGEN from calling tauola, enter the tau to be tracked by GEANT and then directly call tauola when a decay is declared. This is a little more work since I then must figure out the calling interface to tauola from how NEUGEN calls it. This will take a little more work and I think the third method is probably adequate for now.

Looking at the event kinematics

One of the first questions people have when presented with an event file is: "How do I know what went on in this event?" The answer to that question lies in the data structures that record the event kinematics: NeuKin and StdHep.

NeuKin

The NeuKin structure records a summary of the basic event information: the neutrino type; the target nucleon; whether it was a CC or NC event; the event x, y, Q2, and W2 variables; and a collection of 4-vectors to summarize the event.

StdHep

The StdHep structure details the list of particles that went into or came out of the event generator. In addition, for most of the tau decay methods it also records the decay sequence. This structure is essentially a straight copy of the STDHEP /HEPEVT/ common. STDHEP is a package that seeks to unify the format of various Monte Carloes and uses the PDG numbering scheme. You can get documentation at FNAL, online as well as physical hardcopy; one one of the FNAL computers type "setup stdhep" and then look in the directory $STDHEP_DIR.

Note that the vertex information in this structure is given in mm (or mm/c), unlike the GEANT information which uses cm and seconds.

Note that Rob Edgecock has slightly modified the ISTHEP convention to:

0
active final state particle, unless JDAHEP values are filled (then it has decayed).
In the standard this code means "null"
1
active final state particle
2
intermediate state (usually particles that decayed, though NEUGEN also puts such lines in for particles that it re-scatters with it's inter-nuclear scattering) [or that's how I understand it]
3
documentation: these, in our events, are the incoming neutrino, the struck nucleus, and the struck nucleon.

The idhep codes are those defined by the Particle Data Group and can be found in the STDHEP documentation. While I'm at it I should also note the documented but easily missed convention for nuclei ID codes: ipdg = FAAAZZZ00J, where

F
=1, flags the particle as a nucleus
AAA
nucleus A
ZZZ
nucleus Z
J
spin as in 2J+1 (but in our case we assume J=0)

Some notes

In the NeuKin structure there is a variable that carries the 4-vector of the undecayed tau. In addition, the visible (non-neutrino) products of the tau decay will end up in one or more of: the muon(s) P4Mu1 (P4Mu2), the total shower (including electrons) P4Shw, and possibly one of the electron 4-vectors P4El1 (P4El2). The P4Mu1 vector holds the first muon encountered in the StdHep structure, which will be the primary muon in the nu_mu CC case, but will be the muon from the tau assuming there were no other (semi)leptonic decays. Users are also reminded that the electrons are already included in the "shower" 4-vector, and the P4El[12] vectors are explicitly given for convenience.

For all the tau decay methods (except "1"), I plan on inserting a separate entry line into "StdHep" that records the 4-vector and postion of the tau when it decays to fully document what occurred and links to the decay products that were entered as secondaries.

Looking at the tracking information

The actual hit information that is recorded can be found in the Hits/Digits .ddl. The EmuHit structure contains the available information for digitization and eventual event reconstruction. The ISheet number is the tile number counting from low x to high x and then up in y.

Status & Event files

I've promised various people a file of displaced vertex CC tau events. I'm hoping to have such a file ready 10/29 or 10/30 (baring any more obstacles). It will take a little longer to get the code in shape to be entered into the CVS repository.

Update (29 October 1996) .... of course there were problems... I have managed to generate a file of roughly 40 CC tau events using method 3 to generate the displaced vertex. The stack is made of 320 pairs of 1mm Steel plates and 1.14mm thick emulsions (0.2mm air gap between each surface of Fe and emulsion). The S1PL planes were 614cm square with 6 by 6 tiles of emulsion 1m square (I made a typo when attempting to configure it to a single emulsion sheet...sorry, you have to deal with the gaps between sheets). The vertex was restricted to the in the range of planes 5 to 50 (either active or passive).

I asked for 200 events but geant shut down after completing the 42nd event (probably in the 43rd) with a ZEBRA problem. Unfortunately ADAMO overrides the default QNEXT routine with a simple message and STOP. This prevents a traceback and thus makes it impossible to determine the cause. I notice in the first event that there were more 16204 hits in the event, so I suspect that the cause of the problem is a massive event with too many hits.... 

   /afs/fnal.gov/files/data/minos/d3/gminos/emulsion_mtdk3_40evt.fz_gaf
For visualization with "vines" you'll also need the full geometry information: 
   /afs/fnal.gov/files/data/minos/d3/gminos/emulsion_6x6.euclid

Backgrounds

...my musings, mostly... Two possible sources are D's from CC events off strange quarks (which must also be high y so that the muon is mis-identified), and NC events off intrinsic charm quarks. In the COSMOS proposal there is the claim that these can be eliminated via p_t cuts. I don't know if that's also true in our case. With the current version of NEUGEN we can not really get a handle on these possibilities since NEUGEN does not do charm production!

The COSMOS proposal also talks about "whitestar kinks". I'm not really clear what is meant by this term; there's a parenthetical comment that these are "mainly coherent elastic scatters", but that's not all that informative either. In any case I don't know if such events are represented by the event generator NEUGEN.

Robert Hatcher <hatcher@astro.indiana.edu>
Last modified: Thu Oct 31 14:50:59 1996