Xmas PAT Tuple Validation campaign

[ekfriis]

So the next generation PAT tuple has a few changes:

1) tighten event skim (todo) 2) lots of electron&muon regression/corrections from Lindsey 3) photons 4) MVA MET in the PAT tuple

Please everyone post your requests for validation samples here and Tapas & I will submit them. There are still a few pending changes (tau ID tags), but we should get started finding the problems now.

[jjswan33]

VBF_HToTauTau_M-125_8TeV-powheg-pythia6

[lgray]

2012 Muon ID, 2012 Photon ID are validated, as well as the various corrections and isolations.

2012 Electron Id is not validated but I validated by hand the input variables, need to make a module to map that to True/False.

*edit: Not the electron ID

[iross]

I haven't come across any issues in the build itself yet, but I do want to make sure that we use the proper effective area/electron calibration targets. In at least one round of pattuples, the effective area targets weren't getting specified when shipping jobs out, so they just used whatever the default was at the time.

It's not a big deal, since they're easy to run again at the analysis level. I'll dig around a bit to see if this is still possible, but I wanted to raise the (potential) issue.

[ekfriis]

That is all setup here:

https://github.com/uwcms/FinalStateAnalysis/commits/master/PatTools/python/pattuple_option_configurator.py

I think we removed the EG calibration stuff from it, so it needs to be re-added, can you do it?

[iross]

Yeah, I took it out a while ago (when I realized I might as well do it at the analysis level), but I thought Lindsey wanted to add it back in. One of us will make sure it's all there.

On Fri, Dec 7, 2012 at 11:13 AM, Evan K. Friis notifications@github.comwrote:

That is all setup here:

https://github.com/uwcms/FinalStateAnalysis/commits/master/PatTools/python/pattuple_option_configurator.py

I think we removed the EG calibration stuff from it, so it needs to be re-added, can you do it?

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11125039.

[lgray]

Yes, this has been removed but we definitely need to add it back in. Though I think this particular module can be re-run when making ntuples at the analysis level.

-Lindsey

[lgray]

@iross could you put this code back in and give it a test?

[ekfriis]

PS - can you please put the logic for the selection in a separate module (maybe in PatTools/python/electrons) from the option configurator and just import it?

[iross]

@lgray Yeah, I'll do it this afternoon.

@ekfriis You mean the big if/elif block used to figure out which target to use based on the dataset name?

[ekfriis]

yeah exactly

On Fri, Dec 7, 2012 at 12:56 PM, iross notifications@github.com wrote:

@lgray https://github.com/lgray Yeah, I'll do it this afternoon.

@ekfriis https://github.com/ekfriis You mean the big if/elif block used to figure out which target to use based on the dataset name?

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11127470.

[ekfriis]

Hi Josh:

Can you please check:

/hdfs/store/user/efriis//2012-12-10-H2T-Validation/VBF_HToTauTau_M-125_8TeV-powheg-pythia6

[jjswan33]

Seems you removed the ak5PFJets needed for the MVA MET

----- Begin Fatal Exception 12-Dec-2012 03:58:57 CST----------------------- An exception of category 'ProductNotFound' occurred while [0] Processing run: 1 lumi: 878 event: 263101 [1] Running path 'runAnalysisSequence' [2] Calling event method for module PFJetCorrectionProducer/'calibratedAK5PFJetsForPFMEtMVA' Exception Message: Principal::getByLabel: Found zero products matching all criteria Looking for type: std::vectorreco::PFJet Looking for module label: ak5PFJets

[ekfriis]

Yes, we can rebuild them if necssary since we have the PFCands.

See here to rerun:

https://github.com/uwcms/FinalStateAnalysis/blob/master/PatTools/python/patTupleProduction.py#L153

(hopefully in the next weeks you can take MVAMET straight from the pat tuple, but lets validate the leptons first)

On Wed, Dec 12, 2012 at 11:08 AM, jjswan33 notifications@github.com wrote:

Seems you removed the ak5PFJets needed for the MVA MET

----- Begin Fatal Exception 12-Dec-2012 03:58:57 CST----------------------- An exception of category 'ProductNotFound' occurred while [0] Processing run: 1 lumi: 878 event: 263101 [1] Running path 'runAnalysisSequence' [2] Calling event method for module PFJetCorrectionProducer/'calibratedAK5PFJetsForPFMEtMVA' Exception Message: Principal::getByLabel: Found zero products matching all criteria Looking for type: std::vectorreco::PFJet Looking for module label: ak5PFJets

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11283233.

[jjswan33]

Still no good. Now I get a seg fault possibly from the electron trigger matching. Did you remove something needed for trigger matching? Anyway I don't have time to investigate further now.

[ekfriis]

Shit, don't think so. If you figure out what module it's from send me the UW DiTau CVS link

On Wed, Dec 12, 2012 at 11:55 AM, jjswan33 notifications@github.com wrote:

Still no good. Now I get a seg fault possibly from the electron trigger matching. Did you remove something needed for trigger matching? Anyway I don't have time to investigate further now.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11284587.

[jjswan33]

Here is an example job:

/scratch/swanson/VBF125New-SUB-MCH/SUB-MCH-patTuple_cfg-004B56D8-AAED-E111-AB70-1CC1DE1CEDB2

The segfault seems to reference: ElectronTriggerMatcher:triggeredPatElectronsL

Module is here:

process.triggeredPatElectronsL = cms.EDProducer("ElectronTriggerMatcher", src = cms.InputTag("cleanPatElectrons"), trigEvent = cms.InputTag("hltTriggerSummaryAOD"), filters = cms.VInputTag( cms.InputTag('hltEle17CaloIdLCaloIsoVLPixelMatchFilterDoubleEG125','',triggerProcess), ), pdgId = cms.int32(0) )

Which is the following plugin:

http://www.hep.wisc.edu/cgi-bin/cms/cvsweb.cgi/bachtis/UWAnalysis/RecoTools/plugins/MyTriggerMatcher.h?rev=1.1

[lgray]

It's using the HLT Trigger information directly, rather than through PAT. It needs the collection we dropped to save 3% of the patTuple size, this is why it crashes, since there is effectively an unguarded dereferencing of a NULL pointer.

[jjswan33]

Ok then this needs to go back. I have no plans to use pat trigger matching.

[ekfriis]

I didn't delete the hltAODSummary, I just proposed it - Josh never answered so I didn't delete it and now we know for sure :)

So it must be something else then...

E

On Wed, Dec 12, 2012 at 12:22 PM, jjswan33 notifications@github.com wrote:

Ok then this needs to go back. I have no plans to use pat trigger matching.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11285301.

[mverzett]

Hi, while I'm studying the electron charge flip probability I realized that flipped electrons do not have any associated gen particle.

I think that the reason for that is because process.electronMatch.checkCharge = cms.bool(True),

Would it be possible to turn it into False?

Thanks

Mauro

[ekfriis]

This is fine for me if no one else has an objection - we can always require it offline. Mauro can you add it to somewhere near this line:

https://github.com/uwcms/FinalStateAnalysis/blob/master/PatTools/python/patTupleProduction.py#L196

and send a PR?

Evan

On Wed, Dec 12, 2012 at 6:42 PM, mverzett notifications@github.com wrote:

Hi, while I'm studying the electron charge flip probability I realized that flipped electrons do not have any associated gen particle.

I think that the reason for that is because process.electronMatch.checkCharge = cms.bool(True),

Would it be possible to turn it into False?

Thanks

Mauro

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11299538.

[jjswan33]

Hi Guys,

I investigated further a bit on this seg fault. First of all if I removed the electron trigger matching but keep the tau and muon trigger matching then I get a seg fault in the following module it seems:

%MSG-e FatalSystemSignal: PATElectronSelector:TightElectrons 14-Dec-2012 07:17:08 CST Run: 1 Event: 5707 A fatal system signal has occurred: segmentation violation %MSG

  process.TightElectrons = cms.EDFilter("PATElectronSelector",
                            src = cms.InputTag("cleanPatElectrons"),
                            cut = cms.string('pt>10&&abs(eta)<2.5&&abs(userFloat("dz"))<0.2&&abs(userFloat("ipDXY"))<0.045&&userInt("mvaidwp")>0&&(!(userFloat("hasConversion")>0))&&userInt("missingHits")==0&&(userIso(0)+max(userIso(1)+neutralHadronIso()-0.5*userIso(2),0.0))/pt()<0.3'),
                            filter = cms.bool(False)
                        )

So it seems that the changes to the electrons are what is causing this seg fault.

-Josh

[lgray]

There also seems to be a malformed string in your cut.

abs(eta)0 ???

Can you run cmssw in gdb and give us a full backtrace?

[iross]

What version of DataFormats/PatCandidates and PhysicsTools/PatAlgos do you have checked out?

V08-09-42 PhysicsTools/PatAlgos V06-05-06-03 DataFormats/PatCandidates

On Fri, Dec 14, 2012 at 2:23 PM, jjswan33 notifications@github.com wrote:

Hi Guys,

I investigated further a bit on this seg fault. First of all if I removed the electron trigger matching but keep the tau and muon trigger matching then I get a seg fault in the following module it seems:

%MSG-e FatalSystemSignal: PATElectronSelector:TightElectrons 14-Dec-2012 07:17:08 CST Run: 1 Event: 5707 A fatal system signal has occurred: segmentation violation %MSG

process.TightElectrons = cms.EDFilter("PATElectronSelector",

src = cms.InputTag("cleanPatElectrons"), cut = cms.string('pt>10&&abs(eta)0&&(!(userFloat("hasConversion")>0))&&userInt("missingHits")==0&&(userIso(0)+max(userIso(1)+neutralHadronIso()-0.5*userIso(2),0.0))/pt()<0.3'), filter = cms.bool(False) )

So it seems that the changes to the electrons are what is causing this seg fault.

-Josh

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11375986.

[iross]

Actually, it looks like V08-09-47 is the one for PhysicsTools/PatAlgos now:

https://github.com/uwcms/FinalStateAnalysis/blob/043c8457fad4d577b7dc0552c14bd08b976fd3f7/recipe/recipe_53X.sh

On Fri, Dec 14, 2012 at 2:27 PM, Lindsey Gray notifications@github.comwrote:

There also seems to be a malformed string in your cut.

abs(eta)0 ???

Can you run cmssw in gdb and give us a full backtrace?

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11376073.

[jjswan33]

@lgray - It was some weird copy-past thing - the string is fine:

  process.TightElectrons = cms.EDFilter("PATElectronSelector",
                            src = cms.InputTag("cleanPatElectrons"),
                            cut = cms.string('pt>10&&abs(eta)<2.5 &&abs(userFloat("dz")) <0.2&&abs(userFloat("ipDXY"))<0.045&&userInt("mvaidwp")>0&&(!(userFloat("hasConversion")>0))&&userInt("missingHits")==0&&(userIso(0)+max(userIso(1)+neutralHadronIso()-0.5*userIso(2),0.0))/pt()<0.3'),
                            filter = cms.bool(False)                        )

I am not really an expert on gdb I could try but not now since I am in a meeting.

@iross - I just have the default tags of those for 533_patch3

[lgray]

@jjswan33 easy recipe, you do not need to be an expert

gdb cmsRun

//inside gdb

run your_config.py

//wait till it crashes horribly

bt

then copy/paste the output of bt

[mcepeda]

Is there any 7 TeV test-file around?

[iross]

@jjswan33 Try updating to those tags.. I don't know offhand what the default is in 533, but I saw similar segfaults until I updated.

@mcepeda To my knowledge, there's no 7 TeV anything right now.. I think the MVA MET recipe was hosing that setup. @ekfriis is this still true?

[jjswan33]

@iross - The tags seem to have fixed the seg fault. Thanks

[ekfriis]

Yep, Ian had the solution, PAT dataformats updated...

@mcepeda @iross yes, still no 7TeV, gonna work on it today

On Fri, Dec 14, 2012 at 6:35 AM, jjswan33 notifications@github.com wrote:

@iross https://github.com/iross - The tags seem to have fixed the seg fault. Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11378125.

[jjswan33]

So I took a bit of time looking at this VBF sample and:

17 New Events Pass 644 Events now Fail

This is before Mt, charge cuts but with full ID and Isolation

I tried investigating where I am loosing/gaining events and I wasn't able to find any reason with the information that I have available. This tells us that likely it isn't the isolation (Unless it is a huge change) but is likely to be related to Muon ID, Tau Decay Mode finding, or against lepton discriminators. Also I didn't look in detail at e-tau but there is also a difference just looking at file size.

In order to investigate further I would need to skim the events and have them patuplized. Details about the event numbers can be found here:

/afs/hep.wisc.edu/cms/swanson/EventDiff.txt

[ekfriis]

OK Josh, I'll make the skim.

Everyone else - what do you want? 42X is working now :)

[mcepeda]

Great news! I want 1 file of W+Jets and 1 file of TTBar.

[ekfriis]

OK @mcepeda,

/scratch/efriis//smb_ttbar.Dec17-v1.root /scratch/efriis//smb_wjets.Dec17-v1.root

should show up on login05 in a couple hours. Correspond to the AOD files listed here:

https://github.com/uwcms/FinalStateAnalysis/blob/master/PatTools/test/sync/smp_42X.sh

[mcepeda]

Hi,

So I get an error because

Looking for sequence of type: reco::Jet Looking for module label: ak5PFJets

is not found.

Did we remove the reco::Jets ak5PFJets from the patuple?

EDITTED: If we did, I would propose to remove GenJets and save the reco, or maybe at least save ak5JetTracksAssociatorAtVertex in its stead

Best,

Maria

[ekfriis]

Yes, I did. It was about 3% of the space, but it seems you and Josh both use it so I will put it back in! Otherwise it is a waste of CPU...

New sync files coming...

On Tue, Dec 18, 2012 at 7:15 AM, mcepeda notifications@github.com wrote:

Hi,

So I get an error because

Looking for sequence of type: reco::Jet

Looking for module label: ak5PFJets

is not found.

Did we remove the reco::Jets ak5PFJets from the patuple?

Best,

Maria

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11490619.

[ekfriis]

Josh, here are some sync ntuples for you:

/hdfs/store/user/efriis//2012-12-17-H2T-Skim-All
/hdfs/store/user/efriis//2012-12-17-H2T-Skim-Failed
/hdfs/store/user/efriis//2012-12-17-H2T-Skim-Passed

(the second two are the ones that you lost/extras skimmed out)

I'm making 12-18 versions with the ak5PFJets kept right now, they should be done if a few hours. Not sure if you need that or not.

[jjswan33]

I looked at the failed skim. Most of the events seem to have failed the skim so maybe you could check from your side. Will still follow up with the rest of the events, if any.

Josh

[jjswan33]

Forget my previous message, it turns out that they all pass.. Not sure what has happened before, failed job in the patuple or in my analyzer.

About the 17 events that pass I can't really check unless you want to patuple them with the old recipe.

Josh

[ekfriis]

I think what maybe happened was there was a bug that caused events w/ a missing vertex to crash, so perhaps they were my failed jobs.

I'll try and do those 17 events w/ the old recipe today.

On Wed, Dec 19, 2012 at 5:02 AM, jjswan33 notifications@github.com wrote:

Forget my previous message, it turns out that they all pass.. Not sure what has happened before, failed job in the patuple or in my analyzer.

About the 17 events that pass I can't really check unless you want to patuple them with the old recipe.

Josh

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/94#issuecomment-11529187.

[ekfriis]

I suppose we are validated? Closing, cna reopen.