Murad and Carl noticed that the jet trees rerun AFTER the jet trigger fix in the trigger code produced an unexpected change in the number of HTTP triggers:

        http://cyclotron.tamu.edu/star/2005n06Jets/Nov15_2008/comp.html

The Blue spectrum was produced using files: /eliza13/starspin/jetTrees/beta/P081007_skim_2006/fixed/ which were produced OCT-23-08.

The Red spectrum was produced using older files of unspecified date.  Looking back at the changes made to StBemcTriggerSimu.cxx they can be divided into the following time periods:

    JAN:      1-23-08 Dave Added trigger accessors
                1-27-08 corrections to HTTP trigger
   FEB:       2-01-08 Correct Bug in GetTowersAbove
   JUNE:     6-10-08 Correct Bug in check towers with Calib=0
   OCT:    10-08-08 All updates to all layers with Pibero's Fix

So I decided to cvs co code as it was after each of the changes indicated above, compile and then run the trigger code to see how many of the hardware triggers (137611) actually passed emulated triggers.

> cd TriggerComp

> mkdir FebDev

> cd FebDev   

> stardev

>echo $STAR_LEVEL (and verify it is correct)

> cvs co -D 2008-02-03 StRoot/StTriggerUtilities

> cons

> root4star -b -q rdMu2TrigSimu2006.C >& FebOut

> grep SimuTrig FebOut >& FebList

Repeat for JuneDev with date 2008-06-11

Repeat for OctDev with date 2008-10-23

Repeat for UberTrig with most recent cvs co

Repeat for Feb/June/Oct with SL08c instead of DEV

In each of the DEV cases I found 14/112 hardware triggered events for trigID=137611 did not pass the emulated trigger.  Five of these failed at L0 and all 14 failed at L2. My conclusion is that there seemed to be no differences in the # of triggers found in each version of the code. I also checked the towers that were returned as fullfilling the trigger id were the same.  Modulo the initialization error which causes additional junk towers to be returned the same and correct tower was returned in the list for all versions of the code.

In the case of  SL08c, the results differed by month.  February, has only 1/112 hardware triggered events for trigID=137611 which did not pass the emulated trigger. This event had L0=0 and L2=1.  In the case of June and October 5/112 hardware triggered events did not pass the emulated triggers.  For all of these L0=0 and L2=1.

I) First conclusion:  After June the status of towers w/o calibration constants was set to 0 in StEmcADCtoEMaker.  This will result in anything being run in DEV to include this change and any code being run after June 10, 2008 to include this change. The L0 results are exactly the same for all code in DEV and all code in SL08c for June/Oct/Present.   Explicit checks verify this is the case  (see below).

2) Second conclusion:  The only difference between SL08c and DEV is in L2.  How can that be?

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Next I tried to investigate the towers within the SL08c output. If the tower id was significantly different then the geometric trigger will be different. The towers in Feb/Oct are exactly the same except for the events which differ in total emulated trigger output.  For those events the trigger tower is 1078, 2074 (2x), 2075. I verifed that each of these towers has no calibration and therefore will be blocked in the June/Oct runs but not the February runs.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Next I tried to repeat this with the JetMaker code, which also runs StTriggerUtilities in order to fill the skim trees. The changes to the Skim Tree happen at the beginning of February and May 7th so we can repeat the same time periods for the jet code as used for StTriggerUtilities.

> mkdir FebJetCode

> cd FebJetCode

> stardev

> cvs co -D 2008-02-03 StJetMaker

> cvs co -D 2008-02-03 StJetFinder

> cons --  fails CANNOT cons in DEV

> setenv STAR_LEVEL SL08c

> echo $STAR_LEVEL (and get SL08c back)

> RunJetFinder2.C

I found the same results running the jetfinder in SL08c as running only StTriggerUtilities in SL08c.  So the JetFinder is not the issue. I also checked that when the trigger emulator was run with the jet finder the same tower distribution is returned.

------------------------------------------------------------------------------------------------------------------------------------------------------------------