setup to run miniAOD on legacy 80X AOD inputs #19304
Conversation
|
A new Pull Request was created by @slava77 (Slava Krutelyov) for master. It involves the following packages: Configuration/Eras @perrotta, @monttj, @cmsbuild, @franzoni, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
@cmsbuild please test @smuzaffar please take a look at what happened in connection to |
|
The tests are being triggered in jenkins. |
cmsbuild
added
tests-pending
tests-started
and removed
tests-started
tests-pending
labels
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
hi @slava77 - could we not just use the 2016 era instead of defining a new era? This is presumably now the desired miniaod code for 2016 data, right? |
|
I think a new era is better, since this switch is for processig in 9XY the
2016 data reconstructed in 80X (for 2016 data reconstructed in 9XY, the
standard 9XY miniAOD configuration is to be used, not this one)
…On Tue, Jun 20, 2017 at 11:18 AM, David Lange ***@***.***> wrote:
hi @slava77 <https://github.com/slava77> - could we not just use the 2016
era instead of defining a new era? This is presumably now the desired
miniaod code for 2016 data, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19304 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbbR0tSplIdT_IUMeizN3KatM2-85P0ks5sF45KgaJpZM4N86s3>
.
|
|
On 6/20/17 2:18 AM, David Lange wrote:
hi @slava77 <https://github.com/slava77> - could we not just use the
2016 era instead of defining a new era? This is presumably now the
desired miniaod code for 2016 data, right?
As Giovanni clarified: this is a support to read 80X AOD inputs
and to modify parts that are different.
The 2016 era (the Run2_2016) is used in 9X to also create RECO&AOD
consistent with 9X.
Both 9X AOD inputs and 80X AOD inputs can not be supported by the same
era alone.
It's possible to get the same functionality with customization.
Perhaps I'm missing some details.
Please clarify.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19304 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbgVtaZVasWntJNedxgJ20eD4tTL_ks5sF45JgaJpZM4N86s3>.
|
|
ok now I understand, kind of an abuse of the mechanism - but customize is worse. I'll have a look.
… On Jun 20, 2017, at 2:31 PM, Slava Krutelyov ***@***.***> wrote:
On 6/20/17 2:18 AM, David Lange wrote:
> hi @slava77 <https://github.com/slava77> - could we not just use the
> 2016 era instead of defining a new era? This is presumably now the
> desired miniaod code for 2016 data, right?
>
As Giovanni clarified: this is a support to read 80X AOD inputs
and to modify parts that are different.
The 2016 era (the Run2_2016) is used in 9X to also create RECO&AOD
consistent with 9X.
Both 9X AOD inputs and 80X AOD inputs can not be supported by the same
era alone.
It's possible to get the same functionality with customization.
Perhaps I'm missing some details.
Please clarify.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#19304 (comment)>, or
> mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEdcbgVtaZVasWntJNedxgJ20eD4tTL_ks5sF45JgaJpZM4N86s3>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
so lets move forward - however, we lack a mechanism parallel to what we have in other workflow components (eg, -s RECO:trackingOnly) as the configs are unscheduled. Should we not control via a config variable longer term? Eg, one could do -s PAT:redoJets which sets process.miniAODControl.redoJets=1 that propagates down - (I guess this is not so different from eras, but keeps the distinct concepts as distinct. |
|
merge |
|
On 6/20/17 7:17 AM, David Lange wrote:
so lets move forward - however, we lack a mechanism parallel to what we
have in other workflow components (eg, -s RECO:trackingOnly) as the
configs are unscheduled.
Should we not control via a config variable longer term?
Eg, one could do -s PAT:redoJets
which sets process.miniAODControl.redoJets=1 that propagates down - (I
guess this is not so different from eras, but keeps the distinct
concepts as distinct.
These flags will need to apply uniformly to PAT, DQM, and VALIDATION
steps to be somewhat more general.
It's not just about redoing something that can recover the inputs to the
state identical in the current release.
In some cases it's about descoping/abandoning some inputs/outputs which
can not be redone.
I think that this support should be available at process load level,
something that's not possible to override by loading PSet fragments,
similar to Era.
On a quick thought, this all sounds like a proposal for a different
mechanism provided by the era mechanism,
which is fine if so desired.
Once framework can support this, we can make necessary updates.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19304 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbrZHSgyLXdvHArRI4bJauJggBzn3ks5sF9RngaJpZM4N86s3>.
|
Tested in CMSSW_9_2_3_patch1 with the following:
for MC:
for data:
Here are a couple of plots from the MET PD (instructions above):
some things are essentially the same (with recognizeable changes [simple , e.g. p4 kinematics pf packedCandidates is the same)]:
Some things differ more (and I don't obviously recognize the difference
E.g. in slimmedJets (maybe cleaning is not the same? it's the same ak4PFJetsCHS on input from AOD directly)
)
Note that ak4PFJets
@mverzett @kmcdermo @arizzi @gpetruc
@fabozzi please take a look to possibly set up a matrix workflow to have this regularly tested.