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
MTD geometry: porting of MTDTopology to DD4hep #29599
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29599/14934
|
A new Pull Request was created by @fabiocos (Fabio Cossutti) for master. It involves the following packages: Geometry/MTDGeometryBuilder @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+upgrade |
merge |
} else { | ||
dd4hepToken_ = cc.consumesFrom<cms::DDCompactView, IdealGeometryRecord>(edm::ESInputTag()); | ||
} | ||
edm::LogInfo("MTDParametersESModule") << "MTDParametersESModule::MTDParametersESModule"; |
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.
Just noticing this line. Shouldn't it be LogTrace
?
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.
Throughout this PR, shouldn't the LogInfo/LogVerbatim be changed to LogTrace
?
This PR has already been merged, so these changes would have to go in a later PR.
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.
@cvuosalo this is a minimal update of older code, I agree with you that it might be set as optional (even though it is not so far). Anyway 1) Info verbosity is not used in production 2) LogDebug/LogTrace management looks to me quite impractical and cumbersome and 3) it is basically not tested (I have recently made a cleanup PR for many LogDebug lines not even compiling when invoked, because they are generally not probed in regular PR tests). I can move there printouts under EDM_ML_DEBUG flag control as usual in #29647
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.
it is basically not tested (I have recently made a cleanup PR for many LogDebug lines not even compiling when invoked, because they are generally not probed in regular PR tests). I can move there printouts under EDM_ML_DEBUG flag control as usual in #29647h
Code under EDM_ML_DEBUG
has the same risks towards bitrot as LogDebug
, so the only benefit of not using something else than LogDebug
inside #ifdef EDM_ML_DEBUG
is possibly a bit easier configuration of the MessageLogger (LogInfo
needs some as well).
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.
@makortel in this respect you are correct, the simpler update of the default MessageLogger configuration to switch on/off messages is the main reason for this choice of mine (in general we want to comment the declarations of EDM_ML_DEBUG in the code, so my comment 3 is not really relevant in that case). In #29250 my suggestion was to implement a check of the output of compilation with that flag, enabled for the static analyzer, which I understand has been implemented by @smuzaffar in cms-sw/cms-bot#1289
+1 |
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 be automatically merged. |
PR description:
In this PR the existing code describing MTD topology is updated to support DD4hep, both for producer and test analyzer.
PR validation:
The
MTDTopologyAnalyzer
test runs and provide the same results for DD4hep as for DDD on scenarios D50 and D53. As the MTD reco numbering code porting to DD4hep is still under debugging, the test is at present a reduced version of the final one. No impact on production workflows should be expected.