cms-bril / brilws

MIT License
0 stars 2 forks source link

add --l1bit parameter for estimating the integrated luminosity per L1 bit #5

Open mtosi opened 2 months ago

mtosi commented 2 months ago

the current brilcalc lumi allows to estimate the effective integrated luminosity for a given HLT path (by using --hltpath) it would be useful to add the feature for estimating the effective integrated luminosity for a given L1 bit @missirol @silviodonato

xiezhen commented 2 months ago

Hello, given the workload implication of this request, I've asked the BRIL project to justify the request. Some feedback is expected after holliday period. Cheers, Zhen

silviodonato commented 1 month ago

@xiezhen Here a simple use case: You have a HLT path (eg. HLT_MET100) which is seeded by two L1 bits with high and low threshold (eg. L1_ETM120 and L1_ETM100). Because of the high rate, the low threshold L1 trigger (L1_ETM100) is activated only at low luminosity (eg. below 1.5E34), while the high threshold L1 trigger (L1_ETM120) is always unprescaled.

Some analyses are interested to use only the data collected with the low threshold trigger (ie. HLT_MET100 and L1_ETM100). It is very easy to select HLT_MET100 AND L1_ETM100 in NanoAOD, but it is very difficult to measure the integrated luminosity with brilcalc, and therefore it would be great to have the possibility to cut on l1bits on brilcalc.

silviodonato commented 1 month ago

PS. In the MC production all L1 seeds are unprescaled. This means that the efficiency of HLT_MET100 in MC will be equivalent to HLT_MET100 AND L1_ETM100 (because L1_ETM100 is unprescaled in MC). In contrast, in data the actual efficiency of HLT_MET100 will be a mixture between HLT_MET100 AND L1_ETM100 and HLT_MET100 AND L1_ETM120. The exact mixture is given by the ratio of integrated luminosity between the two triggers. Also in this case it would be necessary to allow brilcal to measure the integrated luminosity given a specific L1 bit.