ucatlas / xaodanahelpers Goto Github PK

It would be very useful to have support for cross section scaling via SampleHandler. Perhaps the easiest approach would be to use the methods implemented for SUSY:

https://twiki.cern.ch/twiki/bin/viewauth/AtlasProtected/SampleHandler#Reading_SUSY_meta_data_files

namely:

SH::readSusyMeta(sh,"$ROOTCOREBIN/data/SUSYTools/susy_crosssections_13TeV.txt")

or

SH::readSusyMetaDir(sh,"$ROOTCOREBIN/data/SUSYTools")

It's important that all of the factors (filter efficiency, kfactor, cross-section, number of events, and overal luminosity to which to scale) are supported:

Total Weight = mcevt_weight[0][0] x (Filter Efficiency) x (Cross-section) x (kFactor) x (Lumi) / (Num Events)

The very first factor above is already extracted in BasicEventSelection.cxx#L410:

Read metadata and lumiblocks in mc15.

no trigger stuff in DC14

Info in HelpTreeBase::FillTrigger(): Switch: m_trigInfoSwitch->m_menuKeys
xAODConfigToolForTree FATAL /build1/atnight/localbuilds/nightlies/AnalysisBase-2.3.X/AnalysisBase/rel_nightly/TrigConfxAOD/Root/xAODConfigTool.cxx:130 (virtual uint32_t TrigConf::xAODConfigTool::masterKey() const): Trigger menu not loaded
terminate called after throwing an instance of 'std::runtime_error'
what(): Tool not initialised correctly

util.h is rather bare and is a file we probably do not need to separately maintain. It also does not have header protection which is also bad.

See https://its.cern.ch/jira/browse/ATLASG-70 for more details.

It would be good to create a new up-to-date super-skimmed sample to put into the package, as the one we have now might belong to a too old release.

We might want to use a ttbar 50ns:

AtlasProduction 20.1.4.7 for digitization and reconstruction

For that release I have found the following dataset container:
mc15_13TeV.410000.PowhegPythiaEvtGen_P2012_ttbar_hdamp172p5_nonallhad.AOD.e3698_s2608_s2183_r6630_r6264

We have dijet collaborators working on this and should pull them into git land

Not all consistent in trigger decision tool business
not really a bug but there is no "this is shit" label
Add return_checks to HelpTreeBase - cannot return void

These should probably be deleted now. We don't test them as xAODRootAccess has updated to fix these issues.

To create a git tag and push this to an svn tag, the recommended commands are below. Unfortunately this does not seem to be transferring new files, such as Algorithm.cxx . Is there a better way to set up the svn space?

git tag -a XX-XX-XX -m “Message” vesionHash
git push —tags
git checkout tags/XX-XX-XX
cd ../
svn co —force svn+ssh://[email protected]/reps/atlasinst/Institutes/UChicago/xAODAnaHelpers/trunk xAODAnaHelpers
cd xAODAnaHelpers
svn copy . svn+ssh://[email protected]/reps/atlasinst/Institutes/UChicago/xAODAnaHelpers/tags/xAODAnaHelpers-XX-XX-XX

wrapper of AssociationUtils ASG O.R. tool

CxAODs have them named "EventInfo__Nominal"

Need to review implementation of this section in MuonEfficiencyCorrector.cxx module
Documentation on TWiki is lacking info, and the test macro in the util/ of the ASG package is not self-contained.

Event Skimming and xAOD Outputs

So we need to start moving away from our reliance on a TEnv config file. xAH_run.py will be incredibly useful and flexible if we can start moving towards that, but without stopping people from being old-fashioned and using TEnv config files as usual.

To do this, we need to get rid of the "//!" options in front of anything that is a public member variable that is meant to be configurable. This tells ROOT that the variable is streamable and configurable. This should also be set to a default value in the class constructor initialization.

The empty constructor is not called, so tools are not set to nullptr. If they are not instantiated in the code, then the job will crash on finalize() when these are deleted.

I am currently working in:

-) Checking that the Electron* modules are up-to-date with 2.3.12+ ASG releases, and in case not, update them. One known issue is the major interface change for the Isolation Tool (now usable for both Electrons and Muons) .

-) For the ElectronEfficiencyCorrector module, decorate electrons with a vector with nominal and systematically varied SFs, as it is done by @johnda102 in BTaggingSF module.

Hi all,

I have noticed this.

Since @kratsg wants to have the possibility to directly configure algo data members in his steering macro, he had to get rid of the //! int he header files for configurable data members (e.g, cuts, strings...)

However, as stated in :

https://twiki.cern.ch/twiki/bin/view/AtlasComputing/SoftwareTutorialxAODAnalysisInROOT

, whatever gets initialised in intialize() needs //!, the rest doesn't.
And at the moment the configuration valuues are read via TEnv in configure(), which is called inside initialize().

So, I'd say we either move the call to configure() to another place ( --> histInitialize() ? ) , or we need to put back //! to the configurable data members.

Since the latter would go against what Giordon wants to do, so, the first option makes more sense. But we need to check that histInitialize() is a good place for that.

Still, even leaving as it is now does not produce any crash at runtime. But we don't want any unexpected behaviour either.

Let me know what do you think