search

cms-sw / cmssw

CMS Offline Software
http://cms-sw.github.io/
Apache License 2.0
1.07k stars 4.28k forks source link

review data-specific modifications for RECO related to HCAL noise flagging #27767

Closed slava77 closed 3 years ago

slava77 commented 5 years ago

We (historically) have several settings which are applied specifically for data processing (different from what is done for MC) https://github.com/cms-sw/cmssw/blob/CMSSW_11_0_0_pre5/Configuration/StandardSequences/python/Reconstruction_Data_cff.py To complicate this, for most of the processing eras these should be replaced with customisePostEra* methods from https://github.com/cms-sw/cmssw/blob/CMSSW_11_0_0_pre5/Configuration/DataProcessing/python/RecoTLR.py#L47-L51

In all cases where settings in MC differ from data, the choice is generally assuming that MC does not produce real noise and should not be flagged. This is despite the fact that if real signal looks like noise in bulk, its hits will be rejected in PF reco in real data.

One scenario where this approach is OK is for MC made before prompt reco and data behavior is unknown. In this case, if we do not know in advance if a filter rejects anything in data, it perhaps does not make sense to apply it on MC especially if it can lead to efficiency losses. It seems important in this case to have the hits flagged and still available at least in AOD (but better yet in miniAOD) in MC and in data.

Some examples of flagging of noise-like events in signal would be very useful to see if the current asymmetric approach (MC passes the hits, data rejects them) is more practical compared to a symmetric approach where both data and MC will behave the same.

The goal of this issue is for each case to see if the flag settings can be moved to the common area and apply for both data and MC. Additionally, some clarification is needed if relevant data about cleaned hits is saved in miniAOD (or is it available in AOD).

Detailed discussion, should probably be done by email or HN/egroup. This issue is mostly to track the conclusions to see if anything can/should be done in CMSSW.

Timescale target: 11_X or later (aiming for Run 3 or/and if needed Run 2 software integration or potential reprocessing/rereco tests). Perhaps this can be reviewed during the HCAL days in September.

@mariadalfonso @abdoulline @hatakeyamak @bendavid @lathomas @jaehyeok please check also if the issue correctly describes the settings of severities in parts were they differ between data and MC. I'd be happy to replace it with a more authoritative source if there is one.

slava77 commented 5 years ago

assign reconstruction

cmsbuild commented 5 years ago

New categories assigned: reconstruction

@slava77,@perrotta you have been requested to review this Pull request/Issue and eventually sign? Thanks

cmsbuild commented 5 years ago

A new Issue was created by @slava77 Slava Krutelyov.

@davidlange6, @Dr15Jones, @smuzaffar, @fabiocos, @kpedro88 can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

abdoulline commented 5 years ago

Hi Slava, all,

first a small comment on your first bullet - just to avoid misunderstanding: "Compared to MC which has already cleaning for severity above 11 for all flags" : in MC throughout all the modules there is accepted SeverityLevel=9, above which the hits are rejected. Except for towerMakerPF , where level 11 is accepted: https://cmssdt.cern.ch/lxr/source/RecoParticleFlow/PFClusterProducer/python/towerMakerPF_cfi.py#0056

For HF flags in question assigned SeverityLevel is 11 (both for MC and data): https://github.com/cms-sw/cmssw/blob/master/RecoLocalCalo/HcalRecAlgos/plugins/HcalRecAlgoESProducer.cc#L186 -> https://github.com/cms-sw/cmssw/blob/master/RecoLocalCalo/HcalRecAlgos/python/hcalRecAlgoESProd_cfi.py#L46

Now, if we put aside 2018 HI (re-)reco config issue, which I've come across on Monday, and which we've discussed in a dedicated thread with you (with Andrea Perrotta, Jae, Igor and Chandi included), for which you've promptly submitted already merged PR https://github.com/cms-sw/cmssw/pull/27755 (thank you !) all we have as a difference between MC and data in 2018 (for instance) is HBHENegativeNoise (applied solely to Phase0 HB, as HE is in Phase1, and which is not applied in MC), the rest is the same between MC and data.

Now, looking specifically at this flag in RelVal plots:

(1) this particular bit (No.27) [*] is set for JetHT 2018C (for instance) https://tinyurl.com/y5fodl47 (probability per single HB readout per event < 10^-5)

(2) for MC it can be set (but not used due to low SeverityLevel), but for instance in TTBar PU 2018 at the given statistics (9K events) there is none set: https://tinyurl.com/y3gmuw99

So, looks like MC doesn't mimic (at this level of MC statistics) this particular bit in question. Also, the way we look at it in MC (2) can be done for any MC of special interest (exotic signal which is susceptible to suffer from this particular Phase0 HBHE filter) in Run2 as I've mentioned earlier.

For Run3 (full Phase1 HBHE) it will not be active anyway. So I don't see the problem here.

[*] https://cmssdt.cern.ch/lxr/source/DataFormats/METReco/interface/HcalPhase1FlagLabels.h

abdoulline commented 5 years ago

adding HCAL Noise convener Chandi @cpkar

abdoulline commented 5 years ago

adding HCAL DPG convener Aram @arapyan

slava77 commented 5 years ago

first a small comment on your first bullet - just to avoid misunderstanding: "Compared to MC which has already cleaning for severity above 11 for all flags" : in MC throughout all the modules there is accepted SeverityLevel=9, above which the hits are rejected. Except for towerMakerPF , where level 11 is accepted: https://cmssdt.cern.ch/lxr/source/RecoParticleFlow/PFClusterProducer/python/towerMakerPF_cfi.py#0056

For HF flags in question assigned SeverityLevel is 11 (both for MC and data): https://github.com/cms-sw/cmssw/blob/master/RecoLocalCalo/HcalRecAlgos/plugins/HcalRecAlgoESProducer.cc#L186 -> https://github.com/cms-sw/cmssw/blob/master/RecoLocalCalo/HcalRecAlgos/python/hcalRecAlgoESProd_cfi.py#L46

We do not use towerMakerPF in standard reco. My comment was about particleFlowRecHitHF, which has max severity of 11 for MC for the "Standard" flags (which includes all flags). https://github.com/cms-sw/cmssw/blob/7d08238c1f82053c484e2137efac8ad99e1054e9/RecoParticleFlow/PFClusterProducer/python/particleFlowRecHitHF_cfi.py#L26-L29 The severity threshold of 9 is only for HFLongShort and HFLongShort flags https://github.com/cms-sw/cmssw/blob/2ba5d421e10379d81760a899532b2c991b89c82c/RecoParticleFlow/PFClusterProducer/interface/PFRecHitQTests.h#L104-L117

your comment suggests thought that some other places may have different severity thresholds applied (regular towerMaker). Is there any hit rejection done based on severity for hfreco and hbhereco rechit collections?

abdoulline commented 5 years ago

Slava,

I thought towerMakerPF was used in the past (before moving to RecHits in PF), not now. indeed.

I must admit I don't exactly remember why would SeverityLevel = 11 threshold be applied anywhere. My recollection is that there was some "softening" of either (i) SeverityLevel associated to a particular flag or (ii) SeverityLevel per se but only in HLT configs (and then regular settings applied in Oflline) in the past (Run1), but not in Run2...

I hope our PFlow colleagues can comment on the setting you've pointed out:
maxSeverities = cms.vint32(11,9,9), https://cmssdt.cern.ch/lxr/search?!_filestring=&_string=maxSeverities&_casesensitive=1 Also thresholds vs cleanThresholds in aforementioned PFRecHitQTests.h

For regular towerMaker the value is 9 ("regular") for all spicies of HCAL RecHits including HF : https://cmssdt.cern.ch/lxr/source/RecoLocalCalo/CaloTowersCreator/python/calotowermaker_cfi.py#0105 And I don't see it altered anywhere in its (clones) usage, other then in aforementioned towerMakerPF: https://cmssdt.cern.ch/lxr/search?!v=_filestring=&_string=HcalAcceptSeverityLevel&_casesensitive=1

hatakeyamak commented 4 years ago

There was a related discussion in recent email thread and somewhat related discussion in today's PF meeting. https://indico.cern.ch/event/944298/

Regarding the data-specific modifications for HCAL noise flagging, most of them are now put back to the default value for eras after the phase 1 upgrade, as far as I can tell (and also as Salavat indicated above).

Only remaining data-specific modification should be:

AddFlag(hcalRecAlgos,"HBHENegativeNoise",12) compared to MC settings of 8 PF HBHE hits are rejected with severity > 11

I understand that this flag won't be created after HB moves to phase1 electronics in Run 3, so it won't do anything [1], but I think HCAL DPG plans to put them back to the default value explicitly starting from Run 3 (@abdoulline). Then, we no longer have data-specific modifications in Run 3 and onward. [1] https://cmssdt.cern.ch/lxr/source/RecoLocalCalo/HcalRecProducers/src/HBHEPhase1Reconstructor.cc#0614 https://cmssdt.cern.ch/lxr/source/RecoLocalCalo/HcalRecAlgos/interface/HBHENegativeFlag.h

For HF, we discussed a couple of optimization options for PF noise flagging for HF (these are not about data-specific customization, but simply try to see if additional noise flags will improve physics performance), and will try to follow up.

hatakeyamak commented 3 years ago

https://github.com/hatakeyamak/cmssw/pull/new/HFSignalAsymmetryInPF is the branch for including HFSignalAsymmetry In PF. @abdoulline Does this look right? I wonder if HCAL can help testing this in some collision data from Run 2. I will also ping JME.

abdoulline commented 3 years ago

@hatakeyamak
I take the liberty to include Alexander @toropin as HCAL expert in noise flagging domain.

hatakeyamak commented 3 years ago

Thank you. @abdoulline by the way my note says:

Only change we want to consider is:
AddFlag(hcalRecAlgos,"HBHENegativeNoise",12) compared to MC settings of 8
PF HBHE hits are rejected with severity > 11
    → Stop doing this for Run 3, given that the HBHE phase1 electronics in Run 3.
    The phase1 reconstructor won’t create this flag, but still put it explicitly out of game.
    To be done by HCAL DPG.

https://docs.google.com/document/d/1tBa5q399MkSnY99cL3vILkQLj4d1h4wAgjyzfP-JSR0/edit?usp=sharing Is this still a plan?

abdoulline commented 3 years ago

@hatakeyamak Thank you for the reminder, Kenichi!

Yes, we'd need to add two lines import RecoLocalCalo.HcalRecAlgos.RemoveAddSevLevel as HcalRemoveAddSevLevel HcalRemoveAddSevLevel.RemoveFlag(process.hcalRecAlgos,"HBHENegativeNoise") to Run3 RECO customization right after this one:
https://cmssdt.cern.ch/lxr/source/Configuration/DataProcessing/python/RecoTLR.py#0094 Any of us can do it at our earliest convenence, may be you can "append" it to your submission of HFSignalAsymmetryInPF ?

BTW, in the latter, instead of using bit 5 explictly, you may want to

include "DataFormats/METReco/interface/HcalPhase1FlagLabels.h"

and use HcalPhase1FlagLabels::HFSignalAsymmetry ?

hatakeyamak commented 3 years ago

@hatakeyamak Thank you for the reminder, Kenichi!

Yes, we'd need to add two lines import RecoLocalCalo.HcalRecAlgos.RemoveAddSevLevel as HcalRemoveAddSevLevel HcalRemoveAddSevLevel.RemoveFlag(process.hcalRecAlgos,"HBHENegativeNoise") to Run3 RECO customization right after this one: https://cmssdt.cern.ch/lxr/source/Configuration/DataProcessing/python/RecoTLR.py#0094 Any of us can do it at our earliest convenence, may be you can "append" it to your submission of HFSignalAsymmetryInPF ?

I can try. Do we need it here too: https://cmssdt.cern.ch/lxr/source/Configuration/DataProcessing/python/RecoTLR.py#0099 ? I wonder if there is a more efficient way to do it for both at once.

BTW, in the latter, instead of using bit 5 explictly, you may want to

include "DataFormats/METReco/interface/HcalPhase1FlagLabels.h"

and use HcalPhase1FlagLabels::HFSignalAsymmetry ?

I see. I will think about it.

abdoulline commented 3 years ago 
I don't think HCAL customization (formal, as no real effect is brought

in) is explicitly needed for For Run3 "trackingOnly"... Slava and Joosep will correct us eventually, if needed.

Salavat

On Fri, 9 Apr 2021, Kenichi Hatakeyama wrote:

  @hatakeyamak Thank you for the reminder, Kenichi!

  Yes, we'd need to add two lines
  import RecoLocalCalo.HcalRecAlgos.RemoveAddSevLevel as HcalRemoveAddSevLevel
  HcalRemoveAddSevLevel.RemoveFlag(process.hcalRecAlgos,"HBHENegativeNoise")
  to Run3 RECO customization right after this one:
  https://cmssdt.cern.ch/lxr/source/Configuration/DataProcessing/python/RecoTLR.py#0094
  Any of us can do it at our earliest convenence, may be you can "append" it to your submission of
  HFSignalAsymmetryInPF ?

I can try. Do we need it here too: https://cmssdt.cern.ch/lxr/source/Configuration/DataProcessing/python/RecoTLR.py#0099 ? I wonder if there is a more efficient way to do it for both at once.

  BTW, in the latter, instead of using bit 5 explictly, you may want to
  #include "DataFormats/METReco/interface/HcalPhase1FlagLabels.h"
  and use HcalPhase1FlagLabels::HFSignalAsymmetry ?

I see. I will think about it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, orunsubscribe.[ABGHJWTEPZW4RDTBNNOEDHDTH4J7XA5CNFSM4ILM66CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z LOORPWSZGOGCXKCLA.gif]

hatakeyamak commented 3 years ago

That makes sense. Will try to work on this this weekend.

toropin commented 3 years ago

I checked modifications in code to prepare PFlow objects from HF RecHits, namely, ~RecoParticleFlow/PFClusterProducer/interface/PFRecHitQTests.h and ~RecoParticleFlow/PFClusterProducer/python/particleFlowRecHitHF_cfi.py and these modifications look fine to me.

Alexander

hatakeyamak commented 3 years ago

I am sorry that I couldn't respond sooner, but thank you @toropin for checking. I also made suggested changes by @abdoulline . I am running some local test for sanity check. Then the next step will be to ask POGs to check this change.

hatakeyamak commented 3 years ago

@slava77 with this above PR, which also addressed some HCAL flag setting, can we consider this issue can be closed?

hatakeyamak commented 3 years ago

Pinging as a friendly reminder.

slava77 commented 3 years ago

@slava77 with this above PR, which also addressed some HCAL flag setting, can we consider this issue can be closed?

sorry, I wasn't able to put enough attention to this. It's been two years since the issue was open and the full set of flags in all different options doesn't easily fit in my circular buffer memory (in part due to apparent multi-layer negation logic).

To quote from the issue description:

Some examples of flagging of noise-like events in signal would be very useful to see if the current asymmetric approach (MC passes the hits, data rejects them) is more practical compared to a symmetric approach where both data and MC will behave the same.

The goal of this issue is for each case to see if the flag settings can be moved to the common area and apply for both data and MC. Additionally, some clarification is needed if relevant data about cleaned hits is saved in miniAOD (or is it available in AOD).

There are two PRs mentioned in this issue

So, it looks like we moved in the opposite direction, at least partially, away from closing this issue.

hatakeyamak commented 3 years ago

I believe, in #33520, HBHENegativeNoise was put back to the default value so that it should be the same for both data and MC in Run 3 and onward, so we at least eliminated one asymmetry I thought.

Most of, if not all, data-MC asymmetry seems to be for before the hcal phase1 upgrade, and i am not sure if we can really afford studying data-MC asymmetry in detail for those past eras and revisit the setting.

If the suggestion is to put various modifiers in https://github.com/cms-sw/cmssw/blob/CMSSW_11_0_0_pre5/Configuration/StandardSequences/python/Reconstruction_Data_cff.py https://github.com/cms-sw/cmssw/blob/CMSSW_11_0_0_pre5/Configuration/DataProcessing/python/RecoTLR.py#L47-L51 in a common place, where this "common place" should be? If that's clear, we can probably address it with guidance from @abdoulline et al.

slava77 commented 3 years ago

Thanks for clarifying about HBHENegativeNoise. what about HFDigiTime and HBHEFlatNoise?

I think that editing Reconstruction_Data_cff may be more clear (assuming the overrides in RecoTLR are removed). It seems to me like we should be able to have the implementation more compact and clear this way.

What is the number of the removed rechits? If they are not stored already in the reduced rechit collection(s), perhaps if the size is small, some information about dropped data can be added to AOD or miniAOD.

abdoulline commented 3 years ago

Gentlemen, I don't think we're going to go back to previous ("legacy") eras to unify what was initially designed/thought as separate (MC vs data noise flags treatment)... For Run3 we have now "unified" MC & data HCAL noise flags settings.

abdoulline commented 3 years ago

I've checked Noise flags (SeverityLevel) settings for step3 (edmConfigDump) of wfs: (1) 2018 data 136.874 (2) 2021 MC 11634.0 and the only difference is SeverityLevel of HBHENegativeNoise: 8(12) for MC(data). Now, after https://github.com/cms-sw/cmssw/pull/33520 its SeverityLevel=8 both for MC and data for >= Run3

abdoulline commented 3 years ago

"Reduced" HBHE/HF RecHits collections in AOD contain all the hits with non-0 noise flags. And they are available in "slimmed" RecHits collections in miniAOD https://github.com/cms-sw/cmssw/pull/31375

hatakeyamak commented 3 years ago

So, can we consider this is ok?

slava77 commented 3 years ago

So, can we consider this is ok?

I'm not sure what "this" is in this context. I think that to close this feature more clearly it would be better to have the edits to the different flags in just one place https://github.com/cms-sw/cmssw/issues/27767#issuecomment-864089536

hatakeyamak commented 3 years ago

Okay. I think @abdoulline or somebody from hcal dpg will be a natural person to take care of this part, but I can assist if extra hands are helpful, as I somehow got involved. If there is a support from @abdoulline on the proposed change by @slava77 , I can try to work on this.

abdoulline commented 3 years ago

@hatakeyamak @slava77 I have no reasons to object to Slava's suggestion, even though to me it seems to be more about aestetical/conveniece-wise regrouping of "scattered" re-definitions of the flags severity, than a real practical need. Well, "code reformatting" in some sense... But right now I have the impression (please, correct me if I'm wrong):
(1) it's not about moving customization snippets from RecoTLR.py to Reconstruction_Data_cff.py (historically used from the former), but rather (2) directly putting era-specific HCAL data flags customization (after exising initial lines) into Reconstruction_Data_cff.py (and obviously removing those from RecoTLR_cff.py) in way similar to what's done for >=2017 (both for MC and data "at source") [*], just moving particular flag(s) from one group (PSet) to the other one ?

[*] https://cmssdt.cern.ch/lxr/source/RecoLocalCalo/HcalRecAlgos/python/hcalRecAlgoESProd_cfi.py#0031

slava77 commented 3 years ago

@abdoulline in https://github.com/cms-sw/cmssw/issues/27767#issuecomment-864089536 I did say and mean moving the modifications from RecoTLR.py to Reconstruction_Data_cff.py (with eras/modifiers)

abdoulline commented 3 years ago

@slava77 OK, thank you for confirmation about option (2). I'll try to look early next week how it could be arranged (discussing it with Kenichi @hatakeyamak, as he kindly suggested).

abdoulline commented 3 years ago

@hatakeyamak I've put together a branch with cleaned up RecoTLR.py and extended/updated Reconstruction_Data_cff.py https://github.com/cms-sw/cmssw/compare/master...abdoulline:Data_noise_flags_customization_regrouping It passes our usual test:
runTheMatrix.py -l limited --ibeos --useInput all &

Then compared hcalRecAlgos content (edmConfigDump of step3 config of each wf) w/wo this branch in CMSSW_12_0_X_2021-06-24-1100 for : (1) 136.731_RunSinglePh2016B (2) 136.793_RunDoubleEG2017C (3) 136.874_RunEGamma2018C

(1) yileds the same content (SeverityLevel grouping) in process.hcalRecAlgos = cms.ESProducer("HcalRecAlgoESProducer" <..> w/wo the branch (OK), but both (2) and (3) with the branch "lose" HFSignalAsymmetry flag (it disappears) from group 4: (Level=11) wrt inital setting in https://cmssdt.cern.ch/lxr/source/RecoLocalCalo/HcalRecAlgos/python/hcalRecAlgoESProd_cfi.py#0047 which is preserved in (2) and (3) without branch. I'll try to see how it (HFSignalAsymmetry) got "lost" with the branch... May be you have an idea how it may happen (?)

abdoulline commented 3 years ago

Follow-up: both (2) and (3) recover HFSignalAsymmetry flag for Level=11 (group 4), if I explcitly add the following fragment: 

    4 : dict( RecHitFlags = [
            'HFLongShort',
            'HFS8S1Ratio',
            'HFPET',
            'HFSignalAsymmetry']
  )

to 2017 era customization in the branch: https://github.com/abdoulline/cmssw/blob/Data_noise_flags_customization_regrouping/Configuration/StandardSequences/python/Reconstruction_Data_cff.py#L67

Still don't see how this flag got disappeared (without this fragment)...

hatakeyamak commented 3 years ago

Hi @abdoulline Thank you very much. Just for me to understand, why do you use:

run3_HB.toModify(hcalRecAlgos,
    SeverityLevels = {
        3 : dict( RecHitFlags = [
                'HBHEHpdHitMultiplicity',
                'HBHESpikeNoise',
                'HBHETS4TS5Noise',
                'HBHEOOTPU',
                'HBHEFlatNoise',
                'HBHENegativeNoise']
                ),
        5 : dict( RecHitFlags = []) 
   }
)

rather than just having one line:

    HcalRemoveAddSevLevel.AddFlag(process.hcalRecAlgos,"HBHENegativeNoise",8)

? I thought your option 1 above is clearer and easier to understand, but I could be missing something.

abdoulline commented 3 years ago

@hatakeyamak if you mean two options https://github.com/cms-sw/cmssw/issues/27767#issuecomment-867944154

then Slava has briefly confirmed that option (2) with era/modifiers is the preferred one: https://github.com/cms-sw/cmssw/issues/27767#issuecomment-867976054

I take it as no customization snippets to be present in Reconstruction_Data_cff.py And once era modifiers are involved, I don't see/know the way how to use HcalRemoveAddSevLevel.AddFlag in them, while one can just explicitly modify parameters (PSets) of hcalRecAlgos (ESProducer). If you know how to put HcalRemoveAddSevLevel.AddFlag under era modifier, please, suggest the entire (working) snippet.

I'll probably take this discussion "offline" to HCAL thread (with you in Cc), hoping Alexander, Jae (already included in this issue) and Igor may see something that I'm missing...

abdoulline commented 3 years ago

@slava77 Slava, in view of Kenichi's doubts (see above https://github.com/cms-sw/cmssw/issues/27767#issuecomment-870028689 ), could you, please confirm once again that what you meant in your laconic answer https://github.com/cms-sw/cmssw/issues/27767#issuecomment-867976054 corresponds to the tentative modifications in the branch : https://github.com/cms-sw/cmssw/compare/master...abdoulline:Data_noise_flags_customization_regrouping

slava77 commented 3 years ago

@slava77 Slava, in view of Kenichi's doubts (see above #27767 (comment) ), could you, please confirm once again that what you meant in your laconic answer #27767 (comment) corresponds to the tentative modifications in the branch : master...abdoulline:Data_noise_flags_customization_regrouping

I can confirm my comment. I would like to clarify that that comment implied that the implementation is clear and does not blow up to almost 100 lines. It should be possible to call HcalRemoveAddSevLevel.AddFlag(hcalRecAlgos for each specific modifier with smth like

def _modName(algos):
   HcalRemoveAddSevLevel.AddFlag(algos,"HBHEFlatNoise",12)
someModifier.toModify(hcalRecAlgos, _modName)
abdoulline commented 3 years ago

@slava77 thank you for both confirmation and suggestion. I've admitted earlier (and I must re-admit) I didn't know this rather simple way of era-related executon of particuar algo. I'll try to follow it.

abdoulline commented 3 years ago

@slava77 new branch: https://github.com/cms-sw/cmssw/compare/master...abdoulline:Data_noise_flags_move seems to work fine (SeverityLevel groups are identical w/wo branch) for (1) 136.731_RunSinglePh2016B (2) 136.793_RunDoubleEG2017C (3) 136.874_RunEGamma2018C I'll submit PR later today (after passing via runTheMatrix tests)...

slava77 commented 3 years ago

I'll submit PR later today (after passing via runTheMatrix tests)...

thanks.

abdoulline commented 3 years ago

<...>Please group the modifications for one era in one method<...> I'm afraid I don't quite understand what you mean - something like this for the first run2_25ns_specific case with 2 modifications: 

from Configuration.Eras.Modifier_run2_25ns_specific_cff import run2_25ns_specific
def _modName(algos):
   HcalRemoveAddSevLevel.AddFlag(algos,"HBHEFlatNoise",8)
   HcalRemoveAddSevLevel.AddFlag(algos,"HFDigiTime",8)
run2_25ns_specific.toModify(hcalRecAlgos, _modName)

?

slava77 commented 3 years ago

something like this for the first run2_25ns_specific case with 2 modifications: ...

yes

abdoulline commented 3 years ago

OK, thanks!

hatakeyamak commented 3 years ago

Thank you @abdoulline

hatakeyamak commented 3 years ago

Thank you @abdoulline. @slava77 perhaps now we can consider this is concluded?

slava77 commented 3 years ago

Thank you @abdoulline. @slava77 perhaps now we can consider this is concluded?

I agree, we can close this issue, it is resolved with #34282.

slava77 commented 3 years ago

+1

cmsbuild commented 3 years ago

This issue is fully signed and ready to be closed.