-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NanoAOD prototype [RFC] #20626
NanoAOD prototype [RFC] #20626
Conversation
…tag v1.0 except data files
* new step -s NANO * new event contents NANOAOD, NANOAODSIM * use NanoAODOutputModule if datatier == "NANO", otherwise use PoolOutputModule
The code-checks are being triggered in jenkins. |
+code-checks |
A new Pull Request was created by @gpetruc (Giovanni Petrucciani) for master. It involves the following packages: Configuration/Applications The following packages do not have a category, yet: DataFormats/NanoAOD @perrotta, @monttj, @cmsbuild, @franzoni, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
On 9/22/17 4:53 AM, Giovanni Petrucciani wrote:
Github doesn't allow me to re-open that PR because the branch was
force-pushed, so I had to make a new one.
this is the price you pay for closing the PR in attempt to make less noise
An open PR can still have its' topic branch force-pushed.
|
The tests are being triggered in jenkins. |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
@@ -150,7 +150,8 @@ float pat::PackedCandidate::dxy(const Point &p) const { | |||
float pat::PackedCandidate::dz(const Point &p) const { | |||
maybeUnpackBoth(); | |||
const float phi = float(p4_.load()->Phi())+dphi_; | |||
return (vertex_.load()->Z()-p.Z()) - ((vertex_.load()->X()-p.X()) * std::cos(phi) + (vertex_.load()->Y()-p.Y()) * std::sin(phi)) * p4_.load()->Pz()/p4_.load()->Pt(); | |||
const float pzpt = deta_ ? std::sinh(etaAtVtx()) : p4_.load()->Pz()/p4_.load()->Pt(); | |||
return (vertex_.load()->Z()-p.Z()) - ((vertex_.load()->X()-p.X()) * std::cos(phi) + (vertex_.load()->Y()-p.Y()) * std::sin(phi)) * pzpt; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -42,13 +42,13 @@ class PhotonIDValueMapProducer : public edm::stream::EDProducer<> { | |||
public: | |||
|
|||
explicit PhotonIDValueMapProducer(const edm::ParameterSet&); | |||
~PhotonIDValueMapProducer(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes in this file are in the release already (the same commit IDs and in the same order).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so?
Hi Slava, #20626 (and #20563 before it) was done on top of #20491 so it's no surprise that you find the same commits in the two; if you see them in the same order or you see other commits in between it's just the github display that doesn't do the sorting properly when mapping a graph into a 1d timeline (since it's the same commits and not copies, by definition they are in the same order in the history graph, as it's the same graph) New developments have been already done by many people on top of this PR during, so I'll not rebase it as that would mess up the history of all the rest remaining developments. |
On 10/9/17 9:51 AM, Giovanni Petrucciani wrote:
Hi Slava,
#20626 <#20626> (and #20563
<#20563> before it) was done on top
of #20491 <#20491> so it's no
surprise that you find the same commits in the two; if you see them in
the same order or you see other commits in between it's just the github
display that doesn't do the sorting properly when mapping a graph into a
1d timeline (since it's the same commits and not copies, by definition
they are in the same order in the history graph, as it's the same graph)
you are right, if commit IDs are the same there can be only one actual
order.
Consider the comments as FYI for myself and probably others who may
notice this.
…
New developments have been already done by many people on top of this PR
during, so I'll not rebase it as that would mess up the history of all
the rest remaining developments.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20626 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbtC8kWcxpnFhO9S-XzxJMO2gUk03ks5sqk8TgaJpZM4Pgmh->.
|
dear all,
I propose that we proceed as follow:
|
isInit_(false) | ||
{ | ||
auto vwp = iConfig.getParameter<std::vector<std::string>>("WorkingPoints"); | ||
for (auto wp : vwp) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
auto const &
lheVpt = std::hypot( pup[v.first][0] + pup[v.second][0], pup[v.first][1] + pup[v.second][1] ); | ||
} | ||
|
||
out.addColumnValue<uint8_t>("Njets", lheNj, "Number of jets (partons) at LHE step", nanoaod::FlatTable::UInt8Column); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it doesn't look normal that every event we have to specify types and documentation description string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's an overhead but it gives us the flexibility we need (eg allowing the schema to depend on the configuration) while keeping the output module generic and the code simple (avoid percolating stuff through provenance or run/lumi branches).
we may re-engineer things in the future if the overhead becomes large (now i/o and other physics object code dominate the costs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not just the overhead: this implementation apparently allows changes in format event by event, which sounds dangerous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the nanoaod format is by design less structured.
We made some design choice balancing risks and benefits. We would be happy to discuss this design in any of the XPOG meeting where the NanoAOD format is discussed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what this response means.
Does the Nano format support event-by-event changes in branch/table content?
Please clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in some cases (not in the one above) it does. E.g. HLT bits are allowed to change from one event to another and proper (back)filling of the branches is implemented.
As for the rest, while it is not meant to change event by event, there is no "configuration" of the event content specified explicitelly anywhere (not at compile time in the DataFormats, not explicitely at config time).
The configuration of the branches to write is configured basically at first event.
I do not think this discussion belong to a github PR. If you want to understand why we designed it so, we can have a chat on this topic.
reader_.AddVariable(v,(&values_.front())+i); | ||
i++; | ||
} | ||
// reader_.BookMVA(name_,iConfig.getParameter<edm::FileInPath>("weightFile").fullPath() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this commented out code needed?
Please remove or add comments inline in the code why the commented out block is relevant
@@ -0,0 +1,229 @@ | |||
// -*- C++ -*- | |||
// | |||
// Package: PhysicsTools/NanoAOD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't match the file location.
full path given in the line with \class
doesn't match either.
+1
commented out code noted in PhysicsTools/PatAlgos can be cleaned up in a follow up PR |
@davidlange6 any chance merging this before the next IB ? |
merge |
Rebased #20563, removed data files, relocated dataformats, added first cmsDriver integration (but not runTheMatrix nor DQM yet).
Github doesn't allow me to re-open that PR because the branch was force-pushed, so I had to make a new one.
Some files are still to be relocated from PhysicsTools/NanoAOD to PhysicsTools/PatAlgos (or PatUtils)
Comment #20563 (comment) from @lgray also not implemented yet, it will probably come later in the follow-up of other multithreaded performance issues in https://hypernews.cern.ch/HyperNews/CMS/get/edmFramework/3791.html
@arizzi @peruzzim @emanueledimarco