Trigger not applying / LumiCalc issues about factorytools

[rsmith54]

I'm not exactly sure what's happening here.

@lawrenceleejr , maybe this could explain our factor of 2 problem?

[lawrenceleejr]

This does look like it might be the same factor of two... Or at least might be a hint.

In previous studies, I believe the norm weight is correct because checking against the 0L factory, we got the same norm weight values. I also saw this without pileup reweighting, so this points to the factor of 2 being somewhere in the eventWeight branch. But that might be a hint or a red herring.

@JOliver-GH, we expect the trigger efficiency for data vs MC to be very different. Of course data has more junk in it than the MC for the process we're interested in. But yes perhaps there is something happening with the trigger config. We'll need to check against other xAODAnaHelper examples to see if we have the MC trigger config wrong. i.e. how are the trigger scale factors treated in xAH.

-L

[rsmith54]

Okay finally looking through the code again. By default we have the trigger selection off. I guess @JOliver-GH has it on in his run script though?

[joliver92]

So yes, the trigger is on in this case, as shown in the attachment, now, I’m unsure if what the trigger should be to agree with the data.
I think its likely the lumicalc file is very likely to not be applied.

[cid:3AD4537F-AFB0-448C-8DDB-009474C1B9DF]
On 20 Aug 2016, at 12:26 AM, Russell Smith <[email protected]mailto:[email protected]> wrote:

Okay finally looking through the code again. By default we have the trigger selection off. I guess @JOliver-GHhttps://github.com/JOliver-GH has it on in his run script though?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/117#issuecomment-241041211, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQrdKaTJ2kwPi4ECVeIMLfCRnNG7q--mks5qhcQQgaJpZM4JmEZX.

[rsmith54]

How do you mean? If we aren't doing pileup reweighting we shouldn't need that file so that can't be the origin of the factor we are off.

I guess from your email to PAT help that you want to apply PRW ? If you do you need this twiki https://twiki.cern.ch/twiki/bin/view/AtlasProtected/ExtendedPileupReweighting.

[lawrenceleejr]

But yeah. Ignore the pileup weight for now. Does the factor of two persist? The trigger treatment is curious so let's indeed focus on that.

Which selections does this show up for? ee? mums? emu? What if you restrict yourself to only e or mu triggers, one at a time?

Also @JOliver-GH, to show us the exact setup you're using, it'd be good to keep a fork up to date or even just a dev-Jason branch in this repo up to date so we can just independently grows exactly the setup you use.

[joliver92]

Okay, so i have removed the pileup weight, the only weights which are now being multiplied in are the norm weight, the mcEventWeight and the luminosity, which is being multiplied through in units of pb^-1.

The data I am using has the p-tag p2667. The MC i’m using has the p-tag p2666.

In CalibrateST the muon trigger is: HLT_mu20_iloose_L1MU15_OR_HLT_mu50

I am unsure what trigger is specified for the electron.

I then made selections for ee, mumu and emu, I get the following :

[cid:0C95FED2-B22A-409F-B30F-34BB5930AAD1]
[cid:77987426-4854-4C1F-9157-AEB1CAB8DD00]

[cid:16F72581-8BEF-4607-A8BB-77F2A39CD19B]
the forth one however sticks out as being very out of place and I have no idea why the muon seems to always be higher Pt (if thats the ordering), seeing as for abs(LepPdgid[0]) == 11 & abs(LepPdgid[1])==13, nothing seems to pass.

[cid:1311609B-AE3C-4CC8-AF56-6C226CA8DADA]

how would I restrict myself to e or mu triggers ? I can do it asap but i’ll need to know what exactly to do with that,

Hope this helps a little

As for the Github being up to date, I can do that, I’m a bit uncertain how to fully sync my version with the online version, as I have a lots of Tuples in this folder, is there anything i can do to only sync parts of my folders with my online branch ??

Cheers,

Jason

On 20 Aug 2016, at 2:46 AM, Lawrence Lee <[email protected]mailto:[email protected]> wrote:

But yeah. Ignore the pileup weight for now. Does the factor of two persist? The trigger treatment is curious so let's indeed focus on that.

Which selections does this show up for? ee? mums? emu? What if you restrict yourself to only e or mu triggers, one at a time?

Also @JOliver-GHhttps://github.com/JOliver-GH, to show us the exact setup you're using, it'd be good to keep a fork up to date or even just a dev-Jason branch in this repo up to date so we can just independently grows exactly the setup you use.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/117#issuecomment-241078230, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQrdKaGVUG5ZjNz3R1edy1CJA29SVlszks5qheT2gaJpZM4JmEZX.

[lawrenceleejr]

Hi all,

In dev-Larry, I currently have an up-to-date version setup with SUSYTools and using modern lumicalc/PU files (I've included the former in the repo). Things are working reasonably well. It requires 2.4.X at the moment, but when things get into a release I'll submit a PR.

And @JOliver-GH to restrict yourself to certain triggers, you just need to change the regex in the basicEventSelection config, or you can ask for specific triggers to have passed in your selection algorithm. The trigger decisions are written to the store.

-L