Final State Analysis tools at 13 TeV

[nwoods]

I need to use FSA/UWHiggs to analyze MC I'm generating at 13TeV in CMSSW_6_2_X, but it doesn't look like there is a working recipe for 6_2_X. I'm looking into making my own, with a 13 TeV equivalent of recipe_legacy8TeV.sh. Is anyone already working on this? Is this a doable task, or am I opening a nasty can of worms trying to get a big software package that's new to me working in a new release? What else would I need to change?

[mcepeda]

Hi Nate!

A can of worms it is, but we need to open it... Lets go ahead and we will help you. This should be easier that the horrible hidden root problem.

The potential issues might/will come from packages that we are using as they were in 52X having moved on to some new fancy definition in 62X. Those cases should be documented in the twikis respective (TauPOG, MuonPOG, PhysicsTools, etc etc). It should actually be easy to find the twikis digging a bit.

Since you do not need to synchronize with anybody, this makes our life much easier! You set the baseline, and we all will follow.

What I would do:

• Give it a try compiling blindly the full recipe, but dont waste more than 1 attempt on that, if it does not work it is too complex to fix it from a full environment; we should just rewrite it using it as reference. Clone it into "recipe_625.sh" and lets go from there, step by step.
• I would say that for any module that gives you trouble, and for which for which you cannot find a <15 min answer in a recently actualized, official looking twiki; avoid "cvs history" and go for plain git cms-addpkg in the same release that you use.
• This is obvious, but try compiling often :-), to identify where things go wrong :-). Moreover, before downloading FSA, just try to compile the different modules in 625... Only add it on top if you know that the existing modules compile.

Buena suerte! :-) It should not be terrible, and it is necessary, but it will probably take us a few days.

PS: we might be lucky, and 62X might be so well done that everything goes smooth and you get it done in a couple of attempts. it really should not be terrible.

[nwoods]

OK, I'll give it a shot. As mentioned in the meeting, I'll be away from tomorrow to next Tuesday; I will try to work but no promises on how much I'll get done.

Why are we using cms-cvs-history instead of doing things in the usual way with git cms-addpkg? I'm tempted to just move everything over, but if there's a reason we're doing it that way, I won't mess with it.

Also, how do I know which version of each thing to use? Is that specified by the POGs too?

[mcepeda]

We were using cvs history in what I called "legacy recipe" because what I wanted was to ensure full reproducibility of the existent patuples (or, if you want, grant the posibility to create new patuples for the existing analysis with a minimum of synching headaches). That means that the version of each package really had to be the same as the old with CVS. Since the tags and names were ported to the main cmssw in a slightly anarchic way, the easiest way to do that fast was with the history.

The idea from the start was to move to a fully updated state-of-the-art recipe with the latest and greatest from the POGs, but nobody has had time to do that (yet). It is still on the plans, we should avoid the history thing if possible.

So, for 62X: really go ahead with the moving.

And the POGs should tell you the version/tag/branch, yes.

[lgray]

Hi Maria, Nate,

This this aiming at an analysis of Run2 MC or is this for phase 2 upgrade studies?

From the EGM side, 62X isn't actively supported, the reconstructions, IDs, and energy corrections will work since they're the same as 53X+some niceness ontop. They will be less-than-optimal since they're designed for 8 TeV with 50 ns bunch spacing and 8 TeV pileup (13 TeV PU spectrum is harder, of course).

I would get something that simply works in 62X and save any big effort for 700 and beyond, which is where the major changes are but there won't be any MC until July. On a similar thread there's likely to be quite a bit of ID work on any of the objects you want to use @ 13 TeV, since you said you wanted to set baselines. :-)

-Lindsey

On Wed, Feb 19, 2014 at 12:58 AM, Maria Cepeda notifications@github.comwrote:

We were using cvs history in what I called "legacy recipe" because what I wanted was to ensure full reproducibility of the existent patuples (or, if you want, grant the posibility to create new patuples for the existing analysis with a minimum of synching headaches). That means that the version of each package really had to be the same as the old with CVS. Since the tags and names were ported to the main cmssw in a slightly anarchic way, the easiest way to do that fast was with the history.

The idea from the start was to move to a fully updated state-of-the-art recipe with the latest and greatest from the POGs, but nobody has had time to do that (yet). It is still on the plans, we should avoid the history thing if possible.

So, for 62X: really go ahead with the moving.

And the POGs should tell you the version/tag/branch, yes.

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

[mcepeda]

Hi Lindsey,

Nate can correct me, but this is headed towards Nate (& other students) producing some extra 62X samples to start looking at the prospects for ZZ in 2015. And yes, he cannot wait until July, so I think we have to settle with 62X.

On the other hand, since everything is going to be MC only for a looong while now, today I wouldnt worry very much about the perfect energy calibration - once we have everything setup as an analysis framework, and there are 7XX samples, we will move to 7XX and do things perfectly... implement state of the art ID etc etc... we can ping you and get things in shape to really have nice baselines for 2015 :-).

(On a related topic... since we have you here... Is there an official recipe for the 53X legacy in git for things like electron calibration?)

Maria

[lgray]

Hi Maria,

If you're going to be producing your own samples anyway, I'd recommend you do it in CMSSW_7_0_0 (out since last week). It's not just the energy calibration for E\gamma that's different, there's better isolation schemes, different jet definitions, different rho definitions, and you can recalculate PF met and isolation given your object selections. That and, as you know, entirely new e/gamma and tau reconstructions.

If you do this you also have a stake in making the state of the art ID, instead of using it since the IDs for the old reconstruction pretty much shouldn't/can't be used. If you want to run down that particular path. Sales pitch done. ;-)

Sadly the only official recipe for the electron energy regressions is still CVS based, though I think there is some effort from Volker Adler and Taejeong Kim to move this to git. Try asking them.

You can always get around it by cvs co'ing whatever packages are needed and then git add /git commit those so you stop git's complaining.

-Lindsey

On Wed, Feb 19, 2014 at 9:36 AM, Maria Cepeda notifications@github.comwrote:

Hi Lindsey,

Nate can correct me, but this is headed towards Nate (& other students) producing some extra 62X samples to start looking at the prospects for ZZ in 2015. And yes, he cannot wait until July, so I think we have to settle with 62X.

On the other hand, since everything is going to be MC only for a looong while now, today I wouldnt worry very much about the perfect energy calibration - once we have everything setup as an analysis framework, and there are 7XX samples, we will move to 7XX and do things perfectly... implement state of the art ID etc etc... we can ping you and get things in shape to really have nice baselines for 2015 :-).

(On a related topic... since we have you here... Is there an official recipe for the 53X legacy in git for things like electron calibration?)

Maria

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

[mcepeda]

I'll think Nate (& Matt) should decide the release (I think the issue might be that generating ZZ is painless, but if they need backgrounds... not really if they are going to need DY). No idea.

Regarding the electrons: ok, thanks for the pointer. I have a version of the electron recipe that compiles and runs, using a combination of git cvs history and some porting of files to our own FSA. I just wanted to know if a more elegant setup was available :-).

[herndon]

We are studying the prospects for EWK scattering in ZZ and WZ for 2015.

We could consider upgrading straight to 7XY. However, current the MC group only has a recipe available for MC production in 6XY. The recipe is not trivial in that small deviations from it in terms of releases, tags and geometries cause failures. Finally, the MC group is in the middle of the 6XY campaign. They will will generate ZZ and WZ QCD and DY datasets that we can use as backgrounds.

In general the 6XY release is targeted for MC production. It could be difficult to go off the beaten path and try release 7XY. Also for consistency between our signal and background samples 6XY would be preferred.

For generation it would seem preferable to stick with 6XY. Perhaps at some point we would want to rereco with 7XY, but probably when the MC group decides to do the same thing. A question would be whether you can data reconstructed in 6XY using 7XY

[lgray]

Hi Matt,

Also, the 6XY campaign GEN/SIM will be used as the input for CSA14 in July, which will be in CMSSW 7 and duplicated over three pileup scenarios.

It's a bit tricky to reRECO 6XY GEN-SIM-RECO into 7XY GEN-SIM-RECO, there are too many changed data formats. Of course, one can always start from the GEN-SIM.

If you're looking at electrons or photons, make sure you simulate the OOTPU in the [-300ns,+50ns] time window, to account for OOTPU in the readout of the crystals correctly and use the appropriate GlobalTag for 50ns or 25ns bunch spacing (doesn't matter for GEN-SIM since the PU hits are mixed in later, but matters quite a lot starting with DIGI and onwards).

I recommend you should do your MC production in 3 steps, GEN-SIM, DIGI+HLT, then finally RECO.

This will allow you to change pileup scenarios and reconstruction versions with few problems.

-Lindsey

On Wed, Feb 19, 2014 at 5:24 PM, herndon notifications@github.com wrote:

We are studying the prospects for EWK scattering in ZZ and WZ for 2015.

We could consider upgrading straight to 7XY. However, current the MC group only has a recipe available for MC production in 6XY. The recipe is not trivial in that small deviations from it in terms of releases, tags and geometries cause failures. Finally, the MC group is in the middle of the 6XY campaign. They will will generate ZZ and WZ QCD and DY datasets that we can use as backgrounds.

In general the 6XY release is targeted for MC production. It could be difficult to go off the beaten path and try release 7XY. Also for consistency between our signal and background samples 6XY would be preferred.

For generation it would seem preferable to stick with 6XY. Perhaps at some point we would want to rereco with 7XY, but probably when the MC group decides to do the same thing. A question would be whether you can data reconstructed in 6XY using 7XY

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

[nwoods]

I'm back from California, so I can roll up my sleeves and tackle this. I went through all the POGs' twikis today looking for 62X recipes, and didn't have much luck. The tau folks have a branch that can be easily merged in to use their latest and greatest, and tracking had some somewhat confusing instructions (I guess that tells me what I need, but that git workflow is unfamiliar to me), but I came up empty handed aside from that. Is the proper thing to start bugging experts on all these things? Or is there somewhere else to look (Hypernews or similar?). What do we do if, as Lindsey is hinting, some things just don't have anything for 62X?

[nwoods]

I got the patch issues sorted out and I'm working on compiling. I'm getting compiler errors in EgammaAnalysis/Electron tools, and my best guess is that it comes either from using a deprecated version of the package or from a type issue in CMSSW_6_2_X. I found the current verison of the package, but when I click the 6_2_X branch on github, I just get a 404 error. @lgray, is this what you were warning us about when you suggested CMSSW_7_0_0? Matt is looking into the possibility of redoing the Monte Carlo (for a third time) in 7XY, but we're kind of at the mercy of the generation group.

[nwoods]

It looks like we're going to do this in 7_0_X as part of CSA14. I'm closing this issue for now; I may open a new one if (when) I run into trouble with 7_0_X.