kit-cms / excalibur Goto Github PK

Several quantities overlap in their definition, e.g. pt of mu1, mu2, muplus etc. There are also similarities for puppi and CHS quantities. These may be set both easier and less error prone in a programmatic way.

gen particle status codes are different in madgraph5_aMCatNLO compared to pythia, and also more complicated (see http://www.phy.pku.edu.cn/~qhcao/resources/CTEQ/MCTutorial/Day1.pdf, p25). config for 2015 MC should be adjusted. concerns gen Z and leptons

In the recent JERC meeting, it was suggested that discrepancies in Mu Isolation might stem from incorrectly applied weights of the MC.

http://www-ekp.physik.uni-karlsruhe.de/~cmetzlaff/plots_archive/2015_12_07/puppi_jet_response_uncertainties/mpf_zpt_300-1000.png

We have a slight peak (ok, some events) at R = 0.5 and some around 2. Do you understand these? They can influence the mean and the fit. Is this in all Zpt bins? We should definitely look at all those. Also at over- and underflow bins.

Excalibur can in principle digest Kappa 2 skims using the old interfaces. However, important features such as KGenParticle.pdgId have changed. It is not possible to use Excalibur with the required https://github.com/artus-analysis/Artus/tree/Kappa_2_1.

At the moment, we have zmu1X and mu1X quantities (and mu2, muplus, muminus). In most use cases, mu1 is actually used to represent zmu1. It might be worthwhile to phase out mu1 in favor for zmu1 and complete the zmuX quantities.

In case of muplus/muminus, this seems to be not an issue, as they are by design meant to be zmuplus/zmuminus. Any differences are an error in muplus/muminus. For mu1, there is technically a valid difference, however.

My questions: should mu1 be phased out in favor of zmu1? Should the names also be changed from zmu1 to just mu1?

The test script currently uses the CondFormats version in Georg's web space. This differs from what you get with git cms-addpkg CondFormats/JetMETObjects. The only difference should be that we remove dependencies on CMSSW logging and error handling. The code should otherwise be the same. Currently, there are more than 100 lines different. We do not need parts of the code that care about serialization into ROOT files as we only handle four-vectors of jets within our programs.

A recent CMSSW version should be chosen and the removal of CMS dependencies should be done via a script (sed) to automate the updating in future.

There might be changes in the Type-I correction: "now using ak4PFJetsCHS with pt > 15GeV (before it was ak4PFJets with pt > 10 GeV)". Raphael confirms this.
We should follow the official code.

Currently the pipline names includedes the TaggedJets due to historical reasons.

Since TaggedJets is a global property of a config, it should be removed from the pipeline names.

When lumi/pileup files are already present in the repository, the files are still queried as they are not in the local cache. Is this behaviour on purpose? IMHO if someone else has checked in the files it would be convenient to simply use them

https://twiki.cern.ch/twiki/bin/viewauth/CMS/JetID
https://twiki.cern.ch/twiki/bin/viewauth/CMS/SWGuideMuonIdRun2

The jet composition plots show the HF neutral hadron fraction twice. Should be kept configurable for pre CMSSW 7.3.X samples

Several validations/experiments/trials require just minor modifications to existing configurations, but need to be applied to multiple configs (e.g. for both data and mc). This invariably leads to code duplication for every base configuration.

I propose a method for applying modifications to configurations at the excalibur level. This would be similar in setup to decorators: a modifier takes a single argument, namely the current configuration, and is required to return one: config_modifier(config: dict) -> dict This would also allow chaining them.

For the interface, I suggest simply appending them after the config. For example, excalibur.py data15 mod_run2015D mod_jetid -b would equate to mod_jetid.config_modifier(mod_run2015D.config_modifier(data15.config())). The resulting work name would be data15_mod_run2015D_mod_jetid.

please update the skim of the 13TeV MC including AK4 and AK8 GenJetsNoNu

We currently have a mixture of different naming conventions for pipelines in Excalibur and Merlin, as well as between different versions of each. This should be the mostly (exclusively) the "ak5" vs "AK5" naming. We should unify this in all configs and application.

See also issue #39 on renaming the pipelines. Ideally, both should be done at the same time.

There is apparently some leftover code from initial workarounds for various PUPPI issues. For example, there is a barely documented option to add muons to MET (80bd3c6). Merlin configs possibly have some legacy code as well.

I'd opt for removing any such leftovers on sight, unless they are used somewhere.

The plots from the run2_comparison function have been used heavily in recent presentations. They should have a fixed style so that differences in content are easier to see. Some are malformed, e.g. the extrapolation ratio.

The result of get_npudata.py should always be up-to-date with the used Cert JSON, but requires manual execution. Since it executes very fast and doesn't change that often, integrating it in a config class with caching to automatize it would be an obvious solution.

should be possible with brilcalc, see e.g. https://hypernews.cern.ch/HyperNews/CMS/get/luminosity/499.html

The new skimming config is much cleaner. It makes sense to use the same way for 7+8TeV skims (nice python). Perhaps in a new config to be able to compare the results easily.

The documentation for Excalibur and Merlin available on the CLI is rather brief. This is especially apparent for Merlin (see artus-analysis/Artus#7).

I'd suggest inclusion of important references into the -h options and the creation of man pages.

See also eb68a04.

Maybe use data15 / mc15

http://www-ekp.physik.uni-karlsruhe.de/~dhaitz/plots_archive/2015_07_15/muoniso/overview.html

I changed the ZJetTreeConsumers genlevel outputs to work either with the GenZProducer included for testing or with Artus GenBosonProducers. I will remove the GetGenZ method from ZJetProduct in some days, because it isn't working correctly with actual CMSSW MC.

remove e.g. old 740-742 comparisons

there are two skim files without any events, causing problems for excalibur:
/storage/a/mfischer/skims/2015-07-10_MF_AnyMu_2015_746/MIN_MU_COUNT_2-MIN_MU_PT_8.0/DoubleMu_Run2015B_Jul2015_13TeV/kappa_DoubleMu_Run2015B_Jul2015_13TeV_2.root
/storage/a/mfischer/skims/2015-07-10_MF_AnyMu_2015_746/MIN_MU_COUNT_2-MIN_MU_PT_8.0/DoubleMu_Run2015B_Jul2015_13TeV/kappa_DoubleMu_Run2015B_Jul2015_13TeV_10.root

could you increase the events per job setting?

thanks

check https://github.com/artus-analysis/Excalibur/blob/master/Plotting/python/utility/matplotlib_rc.py and revert a6b4b97

Puppi provides best results when computed without muons. This requires muons to be completely removed from the Puppi collection during skimming before doing any computations. Muons should be added again after the Puppi veto and all derived quantities have been calculated.

a test file to run on can be found here: /storage/8/dhaitz/testfiles/skim_74_mc_ee.root

I am unable to get the reco vs ptcl in the extrapolation plot working. It always gives a 1+1x result.

I've created a patch that automatically extracts the actual input files (instead of wrongly hardcoded ones) but that seems to have no effect either.
extra_diff.txt

My current guess is that it's a problem with undefined values not being filtered out.

The formatting commit hook will also try to modify files which have been changed but are not meant to be committed (yet). This will fail the commit, as the hook requires all changes in files it modifies to be staged/commited/stashed.

This seems unreasonable to me - a file that is not meant to be committed does not need to be formatted implicitly and should also not fail the commit. I suggest that the (formatting) commit hook is set to implicitly check only files which are to be committed.

iterate over gen particles in event and count neutrinos, similar to GenParticleProducer in Artus/KappaAnalysis

the current workflow of ssh-ing to lxplus and executing brilcalc does not work very well for people without CERN accounts. should we implement a manual override or sth.?

When the master of KappaTools is compiled with cmake (as Thomas insists to get it scramified) the scram branch should be compatible with it.

for the Excalibur processor runtime plots, only the mean value for each processor should be displayed in a bar chart

right now we have the DeltaR cut that Max activated. However, this might veto ALL jets containing muons, e.g. reject b-jets with a small muon fraction from semileptonic b decays.

• maybe only veto on jet muon fraction?
• maybe only veto on the muons from Z decay, not all valid muons?

Quoting Mikko for simplicity:
"I addition to graphs of means, it would be great if you could add the graphs of RMS to the combination file as well. I’d use these to commission a proof-of-principle of a global fit for JER as well."

check we're using the latest recommendations from
https://twiki.cern.ch/twiki/bin/view/CMS/JetID#Recommendations_for_13_TeV_data

Analysis would be less error prone and more dynamic if Lumi could be calculated automatically from JSON files. brilcalc is the official tool to extract Lumi for given JSON files.

The functions and templates in configtools.py and defaultconfig.py should be sensitive to 25ns data, with the default being 50ns.