In trying to reproduce the results of the Wbbbar analysis, we have used the lepton, jet and b-tagging information which is processed by the TOPFND code. Unfortunately, we often find slightly different results depending on how the code is run. In investigating the differences, we found several quirks of the code. These are things the experts surely know, however since it is easy to make these mistakes and lose/gain events we would like to document some of the warnings/instruction which are important in using the TOPFND code.

They are:

1) The Top group uses Offline VERSION_7_12

2) The Top group uses the following SVX alignment files:

39101 (For 1A)

51110 (For 1B, 'Internal 3')

This can have a large effect on the Beam Constrained Pt of tracks.

3) The Top group uses SVX+CTC tracks. This can have a large effect for beam constrained momenta as well as strip variable extrapolations.

4) The Top group runs DO_SVX_PAD before running TOPFND. This defines many of the defaults used by the TOPFND code (specifically which alignment file are used as well as which type of tracks are unpacked and used in the TOPFND code.)

5) The TOPFND routines require the TRKS banks.

6) The TOPFND routines do not uniquely specify whether or not the B-Field corrections are run (This is important for run 1A).

In this posting we will try to illustrate why these issues are important and suggest ways of avoiding the problems. We are not suggesting that these are the ONLY or PREFERRED solutions, but rather these are agreed upon solutions which are simple and reproduce the results which are consistant with the official Top group results.

********************************************************************************

1) Effect of SVX code on beam constraints,

***** Symptom: ******

The symptom is that TOPFND gets different results if you use DO_SVX_PAD (SVX pattern recognition and track fitting) or do not use it. The problem is that TOPFND requests beam-constrained momenta for the primary leptons and this is calculated using the beam position data base. The results of going to the database depend on the SVX alignment run number. If the alignment run number is wrong, you get the incorrect beam position and incorrect beam-constrained momenta. There is no error message.

***** Solution: ******

A solution is to always force the SVX run number to be correct. Link in module SVXSMAKE and:

for 1A:

TALK SVXSMAKE SEL_ALIGN 39101 EXIT ! (FOR RUN 1A)

or for 1B:

TALK SVXSMAKE SEL_ALIGN 51110 EXIT ! (FOR RUN 1B, 'INTERNAL 3')

This is the current preferred SVX alignment (it supersedes the popular 1B svxp_latest.align). Note that you do not have to use SVXSMAKE in your path.

********************************************************************************

2) When SVX code is used in the same job as TOPFND, TOPFND uses the SVX track for cuts in ELEVAL.

***** Symptom: ******

The symptom is that TOPFND gets different results for the primary lepton selection depending on whether or not DO_SVX_PAD was run previously in the same job. There is no warning.

The problem is that DO_SVX_PAD deletes TRKS, then repuffs QTRK into TRKS when it is done. On the repuffing, the usual CTC-only fit is put in TRKS, but then the CTC-SVX fit is appended as a second fit result for the track. When TOPFND unpacks lepton tracks using the routine TRK_INFO, the code selects, with no warning, the CTC-SVX fit to define the track parameters. So if you do not run DO_SVX_PAD before TOPFND, the CTC-SVX fit is not available and you find the CTC-only track parameters. If you do run DO_SVX_PAD before TOPFND, by default, you get the SVX track parameters.

***** Solution: ******

A solution is to always run DO_SVX_PAD before you run TOPFND. (Note: It may be possible to simply refit the SVX track to create the second TRKS fit block but we have not investigated this.)

********************************************************************************

3) In 1A data, it is easy to use or not use B-field corrections and not know it.

***** Symptom: ******

The symptom is that you run on an event with DO_SVX_PAD and get a result for your SVX tracks and write that event out, as in a strip or puff job. You then run on your stripped events with DO_SVX_PAD and now get a different result.

From production, the SVX fit version stored in QTRK is 0. When DO_SVX_PAD is run on the event, the version number, in QTRK, is changed to 2. This becomes the stored value in QTRK when the event is written out. If DO_SVX_PAD is run on the event again, it sees a version number of 2. If the version number is 0 the uniform B field correction are applied to the CTC track before it is used to seed the SVX track. If the version number is 2 the non-uniform B field correction are applied which leads to the different SVX results. We have found that this difference can change the electron strip variables by almost 10%.

***** Solution: ******

A solution is to always force the non-uniform B-field corrections to be used when running on 1A data. To do this you should link in the module TRKFIX and in your job use.

TALK TRKFIX FIELD ON RETURN

(Note that you do not have to have TRKFIX in your path.)

********************************************************************************

4) You can run the incorrect JETPROB resolution file and not know it.

To get the JETPROB resolution file, running development library on 1B data (current best alignment, internal 3) you should define the following logical:

$ DEFINE TRKPRB$PAR_FILE USR$ROOT1:[CMIAO.JPBTAG]RESOLUTION_INT_DATA.DAT

Dave Toback and Ray Culbertson

For the Univ. of Chicago Group