Info

Meetings

Plots

Code examples

References for existing DQ

Migration references

Many thanks to everyone who is working on their developments in the new Run 3 monitoring framework - a lot of MRs are coming in, which is great.  I'd like to give a few guidelines/suggestions:
all algorithms that can run on ESD/AOD MUST provide a new-style Python configuration function (aka xxxCfg(flags), see [1] for an example).  This will permit them to be set up by the Run3DQTestingDriver.  They MAY also provide an old-style jobOptions hook, see [2] for an example.  Algorithms that must run on RAW SHOULD provide an old-style jobOptions configuration, so we can test in Reco_tf; they will also eventually have to provide a new-style Python configuration (but this will not be tested for a while). There is an AthMonitorCfgHelperOld class, with the same interface as AthMonitorCfgHelper, to assist in writing an old-style jobOption.
there should be a top-level package configuration function, see e.g. [3].  If your package has only one algorithm, this can just be the function in the previous bullet point, otherwise it should basically configure each sub-algorithm.  The point of this is to provide a single entry point for the top-level steering to configure your package.
the algorithms need to be fully configured in the configuration Python function. That means that the stuff following the "if __name__ == '__main__':" check should not contain any calls to configuration functions other than MainServicesSerialCfg, PoolReadCfg, and the monitoring algorithm's configuration. (In particular, the algorithm configuration needs to set up the geometry or any secondary algorithms that are needed.)  This is to ensure that when the algorithm is configured from the core DQ script, that it includes all needed components. [NOTE: for code that needs to run on RAW this is a bit relaxed, as we will not assume that monitoring is responsible for configuring reconstruction.  You may assume that global reco code will be configured by the calling job.]
for everyone except Trigger, please add a call to your top-level configuration algorithm in [4].  (For Trigger, please follow Elin's instructions.)
do not keep "example" in the name of your algorithm, the configuration functions, etc. - your code is no longer an example (and we want to get rid of the unfortunate Run 1 convention where "example" meant "standard production code")
"fill" can be a somewhat expensive operation.  If you need to fill many identical quantities (e.g. when looping through all hits), the best thing to do is to create a vector of the quantities and call fill() with that (using a Monitored::Collection instead of a Monitored::Scalar).
when you make your MR, please add the "DQ" label so that the central DQ developers get informed (you can add the label at any time after you make the MR in case you forget in the initial submission).
Best,
Peter

[1] https://acode-browser.usatlas.bnl.gov/lxr/source/athena/DataQuality/DataQualityTools/python/DQTDetSynchMonAlg.py
[2] https://acode-browser.usatlas.bnl.gov/lxr/source/athena/DataQuality/DataQualityTools/share/DataQualityMon_jobOptions.py#0067
[3] https://acode-browser.usatlas.bnl.gov/lxr/source/athena/DataQuality/DataQualityTools/python/DataQualityToolsConfig.py
[4] https://acode-browser.usatlas.bnl.gov/lxr/source/athena/Control/AthenaMonitoring/python/AthenaMonitoringCfg.py

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r17 - 2019-11-08 - RustemOspanov
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback