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

Ph2 TK Digitizer software updated for RandomNumberGenerator service #22836

Merged
merged 4 commits into from Apr 13, 2018

Conversation

suchandradutta
Copy link
Contributor

The usage of edm::RandomNumberGenerator reviewed following the comment in [1]. We are now generating random numbers in each event independently. The code is accordingly updated.
@makortel, @boudoul, @emiglior

[1] #22710 (comment)

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 4, 2018

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 4, 2018

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 4, 2018

A new Pull Request was created by @suchandradutta (Suchandra Dutta) for master.

It involves the following packages:

SimTracker/SiPhase2Digitizer

@cmsbuild, @civanch, @kpedro88, @mdhildreth can you please review it and eventually sign? Thanks.
@makortel, @GiacomoSguazzoni, @rovere, @VinInn, @ebrondol, @threus, @dgulhan this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

cms-bot commands are listed here

@boudoul
Copy link
Contributor

boudoul commented Apr 4, 2018

Thanks @suchandradutta , Could you please edit the title mentioning that this is a fix in the random generator usage in the phase2 tracker digitizer to be a bit more explicit ? Also could you please backport to 93X ? Thank you again

@suchandradutta suchandradutta changed the title Phase2 Tracker Digitizer software updated Ph2 TK Digitizer software updated for RandomNumberGenerator service Apr 4, 2018
@suchandradutta
Copy link
Contributor Author

@boudoul yes I shall back port it for 93X once the PR is reviewed and accepted. I hope you agree.

@boudoul
Copy link
Contributor

boudoul commented Apr 4, 2018

sure, thanks

void Phase2TrackerDigitizerAlgorithm::initializeEvent(CLHEP::HepRandomEngine* eng) {
if (addNoise || AddPixelInefficiency || fluctuateCharge || addThresholdSmearing) {

flatDistribution_ = std::unique_ptr<CLHEP::RandFlat>(new CLHEP::RandFlat(*eng, 0., 1.));
Copy link
Contributor

@civanch civanch Apr 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@suchandradutta , it is recommended to use a constructor CLHEP::RandFlat(eng,0.,1.), however, this is also an overhead. It is enough to use use "rengine_->flat(); flatDistribution_ is not needed.

@@ -200,12 +198,12 @@ class Phase2TrackerDigitizerAlgorithm {
const SubdetEfficiencies subdetEfficiencies_;

// For random numbers
const std::unique_ptr<CLHEP::RandFlat> flatDistribution_;
const std::unique_ptr<CLHEP::RandGaussQ> gaussDistribution_;
std::unique_ptr<CLHEP::RandFlat> flatDistribution_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not needed to keep flatDistribution_

Copy link
Contributor

@makortel makortel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@suchandradutta Thanks! I gave some suggestions for further improvements (all not necessarily for this PR).

algomap_[AlgorithmType::InnerPixel] = std::unique_ptr<Phase2TrackerDigitizerAlgorithm>(new PixelDigitizerAlgorithm(iconfig_));
algomap_[AlgorithmType::PixelinPS] = std::unique_ptr<Phase2TrackerDigitizerAlgorithm>(new PSPDigitizerAlgorithm(iconfig_));
algomap_[AlgorithmType::StripinPS] = std::unique_ptr<Phase2TrackerDigitizerAlgorithm>(new PSSDigitizerAlgorithm(iconfig_));
algomap_[AlgorithmType::TwoStrip] = std::unique_ptr<Phase2TrackerDigitizerAlgorithm>(new SSDigitizerAlgorithm(iconfig_));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right-hand side could be written more shortly as std::make_unique<PixelDigitizerAlgorithm>(iConfig); etc.

On a more general note (possibly going beyond this PR)

  • algomap_ could be implemented as std::vector (consumes less memory, faster access)
  • iconfig_ could now be removed if isOTreadoutAnalog parameter would be read to member variable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@suchandradutta Could you actually remove the iconfig_ in this PR? It will have to be either removed or changed to a regular member (not reference, so consumes memory) for premixing. Thanks.

void Phase2TrackerDigitizer::endLuminosityBlock(edm::LuminosityBlock const& lumi, edm::EventSetup const& iSetup) {
algomap_.clear();
edm::LogInfo("Phase2TrackerDigitizer") << "End Luminosity Block";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove this function as it does nothing useful anymore.

Phase2TrackerDigitizer::~Phase2TrackerDigitizer() {
edm::LogInfo("Phase2TrackerDigitizer") << "Destroying the Digitizer";
algomap_.clear();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling clear() is unnecessary (algomap_'s destructor will clean up all its contents automatically).

flatDistribution_.reset(nullptr);
gaussDistribution_.reset(nullptr);
smearedThreshold_Endcap_.reset(nullptr);
smearedThreshold_Barrel_.reset(nullptr);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not needed, unique_ptr default is nullptr.

// Threshold smearing with gaussian distribution:
if (addThresholdSmearing) {
smearedThreshold_Endcap_ = std::unique_ptr<CLHEP::RandGaussQ> (new CLHEP::RandGaussQ(eng, theThresholdInE_Endcap , theThresholdSmearing_Endcap));
smearedThreshold_Barrel_ = std::unique_ptr<CLHEP::RandGaussQ> (new CLHEP::RandGaussQ(eng, theThresholdInE_Barrel , theThresholdSmearing_Barrel));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::make_unique<T>() could be used here as well (if these are still needed, ref. @civanch's comment #22836 (comment)).

@kpedro88
Copy link
Contributor

kpedro88 commented Apr 4, 2018

@boudoul is there a specific need for this in 93X?

@boudoul
Copy link
Contributor

boudoul commented Apr 4, 2018

hi @kpedro88 , I do not have any particularly need. However when I do see in the description of the issue #22710 (adressed by this PR) how not safe it is (with many details explained in this issue) and knowing that 93X is intensively used for MC prod, I would feel better if this fix is also propagated there.

@kpedro88
Copy link
Contributor

kpedro88 commented Apr 4, 2018

Okay, I hadn't read #22710. At some point we plan to leave 9_3_X behind, so unless UPSG is going to stop current production to wait for this, I'm not sure if a backport will get merged. Well, we can still make the backport PR so we have it if needed.

@civanch
Copy link
Contributor

civanch commented Apr 4, 2018

Is there the same issue in run-2 Digi, or only Phase2?

@makortel
Copy link
Contributor

makortel commented Apr 4, 2018

@civanch No, this issue is specific to phase2.

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 7, 2018

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

Pull request #22836 was updated. @cmsbuild, @civanch, @kpedro88, @mdhildreth can you please check and sign again.

@kpedro88
Copy link
Contributor

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 11, 2018

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/27442/console Started: 2018/04/11 19:27

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-22836/27442/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 6263 differences found in the comparisons
  • DQMHistoTests: Total files compared: 29
  • DQMHistoTests: Total histograms compared: 2505375
  • DQMHistoTests: Total failures: 4920
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2500279
  • DQMHistoTests: Total skipped: 176
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.500000000131 KiB( 23 files compared)
  • Checked 119 log files, 9 edm output root files, 29 DQM output files

@kpedro88
Copy link
Contributor

Changes throughout Phase 2 workflows due to difference in random number usage, consistent with statistical fluctuations

@kpedro88
Copy link
Contributor

+1

@civanch
Copy link
Contributor

civanch commented Apr 12, 2018

+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. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

@fabiocos
Copy link
Contributor

@suchandradutta @makortel as far as I can see this PR is complementary to #22874 and not conflicting, right?

@makortel
Copy link
Contributor

@fabiocos Yes, they are independent.

@fabiocos
Copy link
Contributor

+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