Jet corrections always from the txt files? (2012 branch)

[katilp]

@jmhogan Do I understand correctly that the jet correction parameters are read from the txt files in both cases, for the doPat or else?

That's what I read from the comments in the poet_cfg.py config file (they are very clear, thanks!), and it is also in agreement with what I observe when running on 2011 without creating the txt files first.

That's all OK for now. In the longer term, I'm just wondering that as we now have the possibility of having the jet correction db files locally in the container with fast access, could we possibly read them from there without this additional step of first producing the txt files.
Producing the txt files is very well justified if reading them from the db takes ages for every job, but it is an additional step.

I believe it originates from the working mode in the JETMET group as they work within their own framework rather than with CMSSW and AOD.

From what I can read from the Run1 NanoAOD code in development, the corrections parameters are read from the db with this:

https://gitlab.cern.ch/cms-opendata/cms-opendata-nanoaodplus/nanoaodplus_v1/-/blob/master/src/NanoAnalyzer.cc#L4334
and if I follow the code correctly (not easy because of ifndefs/ifdefs), it results to

#include "JetMETCorrections/Objects/interface/JetCorrector.h"
 
[...]

const JetCorrector* corrector = JetCorrector::getJetCorrector(mJetCorr, iSetup);

const float jet_min_pt = 15;
  value_jet_n = 0;
  // for (auto it = jets->begin(); it != jets->end(); ++it) {
  for (reco::PFJetCollection::const_iterator it = jets->begin(); it != jets->end(); ++it) {
    if (it->pt() > jet_min_pt) {
      // note that pt cut is applied to uncorrected jets
      value_jet_ptuncor[value_jet_n] = it->pt();
      value_jet_eta[value_jet_n] = it->eta();
      value_jet_phi[value_jet_n] = it->phi();
      value_jet_mass[value_jet_n] = it->mass();
      double jec = corrector->correction(*it, iEvent, iSetup);
      // copy original (uncorrected) jet;
      reco::PFJet corjet = *it;
      // apply JEC
      corjet.scaleEnergy(jec);
      value_jet_pt[value_jet_n] = corjet.pt();

     [...]

However, it is also easy to provide the correction txt file as they are now in the JEC subdirectory, and it is to be discussed if reading them from the db actually makes the use of code easier or more complicated. Your thoughts?
It certainly also depends on how deeply the way of accessing the correction parameters is rooted in the jet analyzers. I had a look but it is difficult for me to tell.

[jmhogan]

In doPat we just still need a text file for the uncertainty. I'll look at this NanoAOD and see if they found a way to do it without, but we couldn't figure that out last year.

…

On Sun, Jul 4, 2021, 7:25 AM Kati Lassila-Perini ***@***.***> wrote: @jmhogan <https://github.com/jmhogan> Do I understand correctly that the jet correction parameters are read from the txt files in both cases, for the doPat or else? That's what I read from the comments in the poet_cfg.py config file (they are very clear, thanks!), and it is also in agreement with what I observe when running on 2011 without creating the txt files first. That's all OK for now. In the longer term, I'm just wondering that as we now have the possibility of having the jet correction db files locally in the container with fast access, could we possibly read them from there without this additional step of first producing the txt files. Producing the txt files is very well justified if reading them from the db takes ages for every job, but it is an additional step. I believe it originates from the working mode in the JETMET group as they work within their own framework rather than with CMSSW and AOD. From what I can read from the Run1 NanoAOD code in development, the corrections parameters are read from the db with this: https://gitlab.cern.ch/cms-opendata/cms-opendata-nanoaodplus/nanoaodplus_v1/-/blob/master/src/NanoAnalyzer.cc#L4334 and if I follow the code correctly (not easy because of ifndefs/ifdefs), it results to #include "JetMETCorrections/Objects/interface/JetCorrector.h" [...] const JetCorrector* corrector = JetCorrector::getJetCorrector(mJetCorr, iSetup); const float jet_min_pt = 15; value_jet_n = 0; // for (auto it = jets->begin(); it != jets->end(); ++it) { for (reco::PFJetCollection::const_iterator it = jets->begin(); it != jets->end(); ++it) { if (it->pt() > jet_min_pt) { // note that pt cut is applied to uncorrected jets value_jet_ptuncor[value_jet_n] = it->pt(); value_jet_eta[value_jet_n] = it->eta(); value_jet_phi[value_jet_n] = it->phi(); value_jet_mass[value_jet_n] = it->mass(); double jec = corrector->correction(*it, iEvent, iSetup); // copy original (uncorrected) jet; reco::PFJet corjet = *it; // apply JEC corjet.scaleEnergy(jec); value_jet_pt[value_jet_n] = corjet.pt(); [...] However, it is also easy to provide the correction txt file as they are now in the JEC subdirectory, and it is to be discussed if reading them from the db actually makes the use of code easier or more complicated. Your thoughts? It certainly also depends on how deeply the way of accessing the correction parameters is rooted in the jet analyzers. I had a look but it is difficult for me to tell. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVFOJGM2NIT6BHQUJNKGHTTWBHJRANCNFSM47ZERTSQ> .