Unify trigger prescales and trigger decision storage

[ntadej]

Currently we use 3 branches to store trigger decision (vector of strings, vector of pass statuses and overall status). Similarly we use a vector of floats for trigger prescales where one needs to look at passed triggers to figure out which float corresponds to which trigger.

For the lumi-based data weights I used map<string, float>. I honestly didn't test the storage requirements differences between two branches of vector<string> and vector<float>, but personally this is easier to read.

In any case this should be unified at some point - either use multiple branches of simple types or have more complex types in one branch.

[kratsg]

I think perhaps multiple branches of simple types is the way to go. It's easier for people in the long run, isn't it? We also might want to consider how flat of a tuple we care about and always aim for flat tuples where possible for things like HistFitter and conversion to numpy/pandas/hdf5 for other efforts like ML.

[fscutti]

Hi @ntadej, is the information in the maps visualised just as easily when opening a ROOT file? Also, if you want to store the info: passed trigger, prescale of type A, prescale of type B, etc, wouldn't just be easier to add another vector of floats instead of overcomplicating a map or introducing another one?

[ntadej]

You do not generally store prescales for the same triggers as you need a separate lumicalc file for each trigger. That's why we will need another vector of strings.

[fscutti]

Hi @ntadej, if I look at this document in particular pg 7 and 8, I read from lines 186 and 187 that the prescale weight can be computed if all the info is available about

1. The triggers which fired the event
2. The prescales of said triggers

This is true no matter how the prescales are computed, which could be from method 1, 2 or 3 as detailed on pg 7.

So far, it has been extremely easy in xAH to retrieve both information from the two vectors we have, with elements passedTrigger.at(i), prescaleForSaidTrigger.at(i). I think that how the information is stored in the ntuples should not depend at all on how the prescales are computed. Are you just saying that this is impossible? Forgive me for being slow but could you please elaborate on why?