Skip to content
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

Fixing Stat Overflows consideration on DQM modules #32364

Merged
merged 4 commits into from Jan 22, 2021

Conversation

jfernan2
Copy link
Contributor

@jfernan2 jfernan2 commented Dec 2, 2020

PR description:

This PR tries to fix the problem mentioned in #32343 (comment)

The proposed solution goes directly to DQM core setStatOverflows method instead of using teh ROOT method SetStatOverflow since DQM Monitor Elements inherit from there and this prevents modifying many DQM modules around.

I let coding experts to decide if this solution is preferred to directly modify
DQM/SiStripMonitorCluster/src/SiStripMonitorCluster.cc
DQM/SiStripMonitorTrack/src/SiStripMonitorTrack.cc
DQM/SiStripMonitorDigi/src/SiStripMonitorDigi.cc
DQMOffline/EGamma/src/ElectronDqmAnalyzerBase.cc
as suggested on #3234 instead.

I can switch to that strategy if preferred.

I have also noticed that there are many Alignment classes suffering from this too:
https://github.com/cms-sw/cmssw/search?p=1&q=StatOverflows

PR validation:

Checked compilation and some wf running

@jfernan2
Copy link
Contributor Author

jfernan2 commented Dec 2, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 2, 2020

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32364/20209

  • This PR adds an extra 20KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

@mmusich
Copy link
Contributor

mmusich commented Dec 2, 2020

@jfernan2

I have also noticed that there are many Alignment classes suffering from this too:
https://github.com/cms-sw/cmssw/search?p=1&q=StatOverflows

none of those (Alignment classes and macros) is run in central workflows, so I think they cannot do any harm anywhere else.
About:

DQM/SiStripMonitorCluster/src/SiStripMonitorCluster.cc
DQM/SiStripMonitorTrack/src/SiStripMonitorTrack.cc
DQM/SiStripMonitorDigi/src/SiStripMonitorDigi.cc

I think there is an ongoing campaign to remove every direct access to the underlying bare ROOT from the ME within the tracker DQM group (see e.g: this talk )
Wouldn't solution at #32343 going into the opposite direction?
(I am genuinely asking, as I am not expert)
@sroychow @arossi83

@jfernan2
Copy link
Contributor Author

jfernan2 commented Dec 2, 2020

Thanks @mmusich I am open to implement the other solution, I do not know which one is best

@mmusich
Copy link
Contributor

mmusich commented Dec 2, 2020

I do not know which one is best.

IMHO the one you propose here is the better one, but I am definitely not an expert.

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 2, 2020

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32364/20210

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 2, 2020

A new Pull Request was created by @jfernan2 for master.

It involves the following packages:

DQMOffline/EGamma
DQMServices/Core

@andrius-k, @kmaeshima, @ErnestaP, @cmsbuild, @jfernan2, @fioriNTU can you please review it and eventually sign? Thanks.
@barvic, @rovere, @lecriste, @rociovilar this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@jfernan2
Copy link
Contributor Author

jfernan2 commented Dec 2, 2020

please test
Let's see if this solution works without changes

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 2, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 2, 2020

+1
Tested at: b70c590
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13b23a/11253/summary.html
CMSSW: CMSSW_11_3_X_2020-12-01-2300
SCRAM_ARCH: slc7_amd64_gcc900

@missirol
Copy link
Contributor

the approach used in #32343 seems to be in direct contradiction with earlier recommendations from the central DQM group.

One clarification from my side (for what it's worth): I was not aware of those DQM recommendations (@jfernan2 , could you please point to them?). What was done in #32343 was the only way, at that time, to avoid using ROOT's StatOverflows (I think using SetStatOverflows is the better way, since it doesn't cause changes to the outputs of unrelated modules). Of course, if a call to SetStatOverflows becomes available via MonitorElement (as done in this PR), there will be a followup to #32343 to use that instead of doing it via getTH1().

@jfernan2
Copy link
Contributor Author

@missirol in principle DQM methods are working on internal "ROOT" objects:

// const and data-independent -- safe
virtual int getNbinsX() const;
virtual int getNbinsY() const;
virtual int getNbinsZ() const;
virtual int getBin(int binx, int biny) const;
virtual std::string getAxisTitle(int axis = 1) const;
virtual std::string getTitle() const;
// const but data-dependent -- semantically unsafe in RECO
virtual double getMean(int axis = 1) const;
virtual double getMeanError(int axis = 1) const;
virtual double getRMS(int axis = 1) const;
virtual double getRMSError(int axis = 1) const;
virtual double getBinContent(int binx) const;
virtual double getBinContent(int binx, int biny) const;
virtual double getBinContent(int binx, int biny, int binz) const;
virtual double getBinError(int binx) const;
virtual double getBinError(int binx, int biny) const;
virtual double getBinError(int binx, int biny, int binz) const;
virtual double getEntries() const;
virtual double getBinEntries(int bin) const;
virtual double getBinEntries(int binx, int biny) const;
virtual double integral() const;
virtual int64_t getIntValue() const;
virtual double getFloatValue() const;
virtual const std::string &getStringValue() const;
// non-const -- thread safety and semantical issues
virtual void setBinContent(int binx, double content);
virtual void setBinContent(int binx, int biny, double content);
virtual void setBinContent(int binx, int biny, int binz, double content);
virtual void setBinError(int binx, double error);
virtual void setBinError(int binx, int biny, double error);
virtual void setBinError(int binx, int biny, int binz, double error);
virtual void setBinEntries(int bin, double nentries);
virtual void setEntries(double nentries);
virtual void divide(const MonitorElement *, const MonitorElement *, double, double, const char *);
virtual void setBinLabel(int bin, const std::string &label, int axis = 1);
virtual void setAxisRange(double xmin, double xmax, int axis = 1);
virtual void setAxisTitle(const std::string &title, int axis = 1);
virtual void setAxisTimeDisplay(int value, int axis = 1);
virtual void setAxisTimeFormat(const char *format = "", int axis = 1);
virtual void setTitle(const std::string &title);
// additional operations mainly for booking
virtual void setXTitle(std::string const &title);
virtual void setYTitle(std::string const &title);
virtual void enableSumw2();
virtual void disableAlphanumeric();
virtual void setOption(const char *option);
virtual double getAxisMin(int axis = 1) const;
virtual double getAxisMax(int axis = 1) const;
// We should avoid extending histograms in general, and if the behaviour
// is actually needed, provide a more specific interface rather than
// relying on the ROOT behaviour.
DQM_DEPRECATED
virtual void setCanExtend(unsigned int value);
// We should decide if we support this (or make it default)
DQM_DEPRECATED
virtual void setStatOverflows(unsigned int value);

so, to avoid colliding modifications which are difficult to track, direct ROOT modifications are not desired

@jfernan2
Copy link
Contributor Author

ping @sroychow @arossi83

@mmusich
Copy link
Contributor

mmusich commented Jan 18, 2021

@cmsbuild please test

@mmusich
Copy link
Contributor

mmusich commented Jan 18, 2021

@jfernan2,
Alessandro (@arossi83) is trying to reproduce locally but doens't seem to see the same things as the bot. I am retriggering the tests in order to get a fresh comparison.

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13b23a/12328/summary.html
COMMIT: d2c2ace
CMSSW: CMSSW_11_3_X_2021-01-17-2300/slc7_amd64_gcc900

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 37
  • DQMHistoTests: Total histograms compared: 2716961
  • DQMHistoTests: Total failures: 4271
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2712668
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 36 files compared)
  • Checked 156 log files, 37 edm output root files, 37 DQM output files

@arossi83
Copy link
Contributor

arossi83 commented Jan 22, 2021

@jfernan2

We investigate a little bit the difference we see, in particular on PixelPhase1 plots.
The differences are due to the fact that now the SetStatsOverflows applies only to the specific ME and not on the Global behavior of the ROOT object as before. Due to this PixelPhase1 plots are by default with StatsOverflows disabled.

I introduce a quick&dirty patch to verify this by manually enabling StatsOverflows for PixelPhase1 plots. In attachment you can find a plot with overlayed this PR, the baseline and the PR+Patch. You can see that by re-enabling the StatsOverflows no changes arise for Phase1 plots.
Test_StatOverflow

In light of that the hold can be removed from this PR so that it can be merged. We will fix the TrackerDQM part with a separate PR.

@jfernan2
Copy link
Contributor Author

Thank you very much @arossi83 !!

@jfernan2
Copy link
Contributor Author

unhold

@cmsbuild cmsbuild removed the hold label Jan 22, 2021
@jfernan2
Copy link
Contributor Author

@amassiro would you be so kind to perform the followup to #32343 you mentioned below? Thanks

One clarification from my side (for what it's worth): I was not aware of those DQM recommendations (@jfernan2 , could you please point to them?). What was done in #32343 was the only way, at that time, to avoid using ROOT's StatOverflows (I think using SetStatOverflows is the better way, since it doesn't cause changes to the outputs of unrelated modules). Of course, if a call to SetStatOverflows becomes available via MonitorElement (as done in this PR), there will be a followup to #32343 to use that instead of doing it via getTH1().

@missirol
Copy link
Contributor

@amassiro would you be so kind to perform the followup to #32343 you mentioned below? Thanks

(i guess the message was for me.. :))

Yes, will do, as soon as this is merged.

@jfernan2
Copy link
Contributor Author

Oh yes, sorry, github misled me. Thank you @missirol !

@jfernan2
Copy link
Contributor Author

+1

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

@qliphy
Copy link
Contributor

qliphy commented Jan 22, 2021

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants