Trigger Accounting Details

Information available:

I. daqTriggerId: in the raw data file, in the DATAP bank (see /RTS/include/daqFormats.h and same include file offline somewhere and the raw datafile format document on STAR->GROUP DOCUMENTS->DAQ), for every event, the L3_SUMMARY[0] field contains a 32-bit bitmask. Each bit that is set corresponds to a trigger satisfied by this event. The index of this bit is the daqTriggerId, a number between 0 and 31 for which the meaning changes every run.

II. daqTriggerId: the daqTriggerId is also available for every event in the event tag database (onlsun1: port=3503, db=RunLog_daq, table=daqEventTag, field=l3_trg_bits).

III. The map from the daqTriggerId to the offlineTriggerId (a number from 1 – 2^32 for which the meaning never changes) is contained in the conditions database. This contains N entries for every run, where N is the number of triggers that were defined for that run.

(onlsun1:port=3501, db=Conditions_rts, table=trgId)

int idx_rn; // the run

int idx_trg;

int daqTrgId; // bit in L3_Summary[0]

int offlineTrgId; // identifier bit to offline

int trgNameVersion;

int trgVersion;

int threashVersion;

int psVersion;

IV. The fully qualified trigger definition INCLUDES the versions. It is possible that there would be two min-bias triggers defined in the same run, for example. They might be completely different triggers. (One might have a different vertex cut for example).

V. There is also a name associated with each trigger. This can be obtained from the Conditions database as well:

(onlsun1, port=3501, database=Conditions_rts, table=triggers)

int idx_rn;

int idx_trigger;

char name[DB_MAX_STR_LEN];

int offlineBit;

(....)

VI. Trigger Versioning: There are four separate versions for each trigger:

trgNameVersion – This should always stay pretty much the same...it is in place in case the name changes for the same offline bit. The trgNameVersion is different if:

The offline bit is different

the name is different

trgVersion – This is meant to indicate that the trigger definition has changed. It is different if:

The tier1 filename is different

Any L0 conditions do not match exactly

the trgCmd/daqCmd request does not match exactly

The L1/L2/ or L3 algorithm does not match exactly

threashVersion – The is meant to indicate that the threashold values have changed. It is different if:

Any DSM register value is different

Any L1/L2 or L3 parameter is different

psVersion – The psVersion is meant to indicate that the pre-scales are different.

VII. Explanations of the difference between trigger versions: Each version will have a comment associated with it, explaining what it was. These comments are in the conditions database:

(onlsun1: port=3501, db=Conditions_rts, table=trgNameHash, trgVersionHash, threashHash, & psVersionsHash respectively)

int version;

unsigned int hash;

char comment[VARCHAR_LENGTH];

VIII. I will have web pages with the various trigger names, ids and versions documented. These are currently under development.

IX. Scalers: There are scalers and counters available for each trigger at each trigger level. L0, L1, L2 & L3. These are available in the Scalers_rts database.

(onlsun1: port=3501, db=Scaler_rts, table=scaLxCounts)

int idx_rn;

int idx_level;

int idx_level_inst;

int idx_trigger;

int idx_period;

unsigned int beginTime;

unsigned int endTime;

int numSeen;

int numAccepted;

int numRejected;

int numPhysSeen;

int numPhysAccept;

(onlsun1: port=3501, db=Scaler_rts, table=scaDaqScaler)

int idx_rn; // run number

int idx_period; // readout period

unsigned int beginTime; // unix time for counting period

unsigned int endTime;

int type; // RC (jeff) = 1

int id;

unsigned int numSeen;

X. Things to look out for in the scaler information:

· The run is broken up into periods of a set length (30 sec to 120 sec) . The first period starts when the first event arrives at EVB.

· The periods MAY not be of equal size. The reason is that periods end when the run pauses or stops.

· The idx_period flag has the following value: 10000 * flag + idx, where idx is a number that increases from 1 to N, and flag is either

a. 0 -> regular period

b. 1 -> start run

c. 2 -> pause run

d. 3 -> resume run

e. 4 -> stop run

· The idx_level corresponds to which trigger L1, L2 or L3

· The idx_level_inst corresponds to which trigger instance. This is because L3 has three independent GL3 nodes which each produce counters. To get the full counters for L3 you need to add all of the instance values together. This may eventually be true for L2 as well.

· For the L1/L2 & L3 the counters count events that are seen by the trigger. That means that the event passed all criteria for the trigger at lower levels including the lower level pre-scales.

· At L0, the counters count events for which the physics was satisfied. The event might not get to L1 because the detectors were busy or because the prescale was not met. However, knowning the prescale and the counters from L1, one can deduce the deadtime and from there can deduce the cross-section (per bunch crossing).

XI. It should be understood that the same event on tape satisfies 1 OR MORE triggers. In some analyses this could lead to double-counting and the users will have to handle this.

XII. Suggested interface to offline StAnalysisMaker:

I suggest offering a set of functions:

isEvent(int trigger);

isEvent(int trigger, int trgVersion,

int threshVersion, int nameVersion, int psVersion);

isEvent(int trigger, int trgVersion, int threshVersion);

isEvent(int trigger, int trgVersion[], int threshVersion[]);

Of which the average user would use the last version with some pre-defined version arrays...

One would also want functions for the scalers:

bunchCrossingsRepresented(int run, int trigger)

bunchCrossingsRepresented(int run, int trigger, int scalerPeriod);

which give the cross section that each event in the trigger represents.

And possibly

detectorDeadTime(int run, int trigger)

detectorDeadTime(int run, int trigger, int scalerPeriod)

XIII. Finally, I would suggest that the data for the above functions should be pulled from the databases at reconstruction time and stored in the dst’s...