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
E/gamma T&P Offline DQM : 92X + VID + GenericTrigEventFlag Changes #19046
Merged
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
32a8b63
initial version
Sam-Harper cc642e9
refactor for readability and fill descriptions
Sam-Harper e8e3b72
updating to use VID and generic trigger event
Sam-Harper 4a42e67
allowing VID to gracefully fail if the input collection is invalid
Sam-Harper fb1a3f4
initial version
Sam-Harper 4ff545f
refactor for readability and fill descriptions
Sam-Harper 9dffa8b
updating to use VID and generic trigger event
Sam-Harper 6f31866
allowing VID to gracefully fail if the input collection is invalid
Sam-Harper 877022b
merging in python changes
Sam-Harper fa5525c
reverting changes to VID
Sam-Harper 9636bcf
removing egammaHLT DQM from HI
Sam-Harper File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
#ifndef DQMOffline_Trigger_FunctionDefs_h | ||
#define DQMOffline_Trigger_FunctionDefs_h | ||
|
||
//*************************************************************************** | ||
// | ||
// Description: | ||
// These are the functions we wish to access via strings | ||
// The function returns a std::function holding the function | ||
// Have to admit, I'm not happy with the implimentation but fine | ||
// no time to do something better | ||
// | ||
// There are various issues. The main is the awkward specialisations | ||
// needed for the different types. Its a nasty hack. Probably | ||
// can do it cleaner with ROOT dictionaries | ||
// | ||
// Useage: | ||
// 1) define any extra functions you need at the top (seed scEtaFunc as example) | ||
// 2) generic functions applicable to all normal objects are set in | ||
// getUnaryFuncFloat (if they are floats, other types will need seperate | ||
// functions which can be done with this as example | ||
// 3) object specific functions are done with getUnaryFuncExtraFloat | ||
// by specialising that function approprately for the object | ||
// 4) user should simply call getUnaryFuncFloat() | ||
// | ||
// Author: Sam Harper (RAL) , 2017 | ||
// | ||
//*************************************************************************** | ||
|
||
#include "FWCore/Utilities/interface/Exception.h" | ||
|
||
#include <vector> | ||
#include <functional> | ||
|
||
#include "DataFormats/EgammaCandidates/interface/GsfElectron.h" | ||
|
||
namespace hltdqm { | ||
//here we define needed functions that otherwise dont exist | ||
template<typename ObjType> float scEtaFunc(const ObjType& obj){return obj.superCluster()->eta();} | ||
|
||
|
||
//additional functions specific to a given type (specialised later on) | ||
template<typename ObjType> | ||
std::function<float(const ObjType&)> getUnaryFuncExtraFloat(const std::string& varName){ | ||
std::function<float(const ObjType&)> varFunc; | ||
return varFunc; | ||
} | ||
|
||
//the generic function to call | ||
template<typename ObjType> | ||
std::function<float(const ObjType&)> getUnaryFuncFloat(const std::string& varName){ | ||
std::function<float(const ObjType&)> varFunc; | ||
if(varName=="et") varFunc = &ObjType::et; | ||
else if(varName=="pt") varFunc = &ObjType::pt; | ||
else if(varName=="eta") varFunc = &ObjType::eta; | ||
else if(varName=="phi") varFunc = &ObjType::phi; | ||
else varFunc = getUnaryFuncExtraFloat<ObjType>(varName); | ||
//check if we never set varFunc and throw an error for anything but an empty input string | ||
if(!varFunc && !varName.empty()){ | ||
throw cms::Exception("ConfigError") <<"var "<<varName<<" not recognised "<<__FILE__<<","<<__LINE__<<std::endl; | ||
} | ||
return varFunc; | ||
} | ||
|
||
|
||
template<> | ||
std::function<float(const reco::GsfElectron&)> getUnaryFuncExtraFloat<reco::GsfElectron>(const std::string& varName){ | ||
std::function<float(const reco::GsfElectron&)> varFunc; | ||
if(varName=="scEta") varFunc = scEtaFunc<reco::GsfElectron>; | ||
else if(varName=="hOverE") varFunc = &reco::GsfElectron::hcalOverEcal; | ||
return varFunc; | ||
} | ||
|
||
|
||
} | ||
|
||
|
||
#endif |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Hi @Sam-Harper - given the GenericTriggerEventFlag(config,iC,false) call, is this needed?
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.
Hi David,
Many thanks for the review. So I think this not strictly needed but it does simplify things for me.
I wanted to leave the original public constructor:
https://github.com/Sam-Harper/cmssw/blob/9636bcf9626f001993f6d941c1b598a8b7eb3a13/CommonTools/TriggerUtils/interface/GenericTriggerEventFlag.h#L157-L169
exactly as is. Which means all the l1 setup gets done outside the private constructor (which is now tagged with an extra argument of a bool). A dirty little secret, that bool is only there to identify the private contructor,
https://github.com/Sam-Harper/cmssw/blob/9636bcf9626f001993f6d941c1b598a8b7eb3a13/CommonTools/TriggerUtils/src/GenericTriggerEventFlag.cc#L130-L135
could easily just be at the location you mention and inside the config.exists("andOrL1") statement. But I put it in the private constructor simply because I didnt like having an unused variable.
As written, it is simpler to have all the L1 construction happening in the public constructors and a shared private constructor which does the rest of the setup. Note, the false only means it is an error that stage-1 is selected, stage-2 can be setup.
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.
ok, it seemed like it was just repeating things to me. Thanks to for the explanation.