-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
PPS: update of Validation/CTPPS #28492
Conversation
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28492/12937
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28492/12943
|
A new Pull Request was created by @jan-kaspar for master. It involves the following packages: CalibPPS/ESProducers @perrotta, @andrius-k, @Dr15Jones, @schneiml, @kmaeshima, @cvuosalo, @civanch, @tlampen, @christopheralanwest, @ianna, @mdhildreth, @cmsbuild, @franzoni, @jfernan2, @fioriNTU, @slava77, @ggovi, @pohsun, @tocheng 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 |
if (found != std::string::npos && sensor_name.substr(found - 4, 3) == DDD_CTPPS_PIXELS_SENSOR_TYPE_2x2) { | ||
m_sensorType = DDD_CTPPS_PIXELS_SENSOR_TYPE_2x2; | ||
} | ||
} |
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 would be good to create a second version of this constructor that takes the new DD4hep cms::DDFilteredView
, either in this PR or a follow-up PR. We are at the end of the DD4hep migration, so this code that uses old DD will need to be eliminated in a few months.
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.
Absolutely correct! The DD4Hep migration (and reco-geometry storage in DB) have been started in parallel. @malbouis is leading this task. The ETA is March 2020 - is this OK? Our roadmap is sketched here: https://indico.cern.ch/event/866706/contributions/3652254/attachments/1952609/3242097/pps_geometry_dd4hep.pdf .
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 , I think, that migration to DD4hep should be done in following PRs not here.
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.
@jan-kaspar Thanks for the info. That is very helpful.
+1 |
@ggovi May I please ask for review? Db is the last signature missing and the changes in CondFormats are small and technical:
Thanks in advance! |
+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 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) |
Thanks @ggovi ! |
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.
@jan-kaspar why are alignment configuration files store inside Validation/CTPPS instead of some alignment package?
edm::ESProducts<std::unique_ptr<LHCInfo>> CTPPSLHCInfoRandomXangleESSource::produce(const LHCInfoRcd &) { | ||
auto output = std::make_unique<LHCInfo>(); | ||
|
||
// TODO: this doesn't work, use temporarily ROOT code |
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.
@jan-kaspar @pohsun why all this? There is no reproducibility guaranteed in this code as far as I can see...
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.
Sorry, I should have pre-discussed with you. As you may know, the xangle has an important impact on what/how PPS can see. I've been asked by the POG to make a simulation where the xangle would be generated randomly according to a specified histogram (e.g. as from LHC data for a given JSON selection). My attempt is the code currently in the PR and I acknowledge it has issues. What would be your recommendation?
The "direct simulation" comes with settings for 5 periods (2016 pre-TS2 and post-TS2, 2017 pre-TS2 and post-TS2, 2018) which reflect the most important changes of conditions relevant for PPS in Run2. The settings consist of python configs and alignment files. Currently, the python configs are in Validation/CTPPS/python/simu_config. In order to have the alignment files in a similar place, they were put in Validation/CTPPS/alignment. Would you have a better suggestion? |
@jan-kaspar I understand that this is a kind of non-standard validation package, so for the few comments I made I can accept the proposed solutions. We have other cases of calibration ESProducers using random numbers with various kind of configurations. In principle CLHEP might be used here, and I understand that the lack of reproducibility is known and acceptable for the purpose of this code. |
Thanks @fabiocos ! I will push (~tomorrow) a small patch to use CLHEP instead of ROOT and to have a python-configurable seed parameter for at least a basic reproducibility. |
+1 |
PR description:
This is an update of code in Validation/CTPPS which has been used extensively in 2019 to prepare proton-reconstruction SW and conditions for the UL re-reco. It also contains "direct" simulation used to study proton-reconstruction uncertainties and more.
It was necessary to make several changes outside the Validation/CTPPS directory. These changes are mostly small and technical (details follow) and introduce no change in proton-recontsruction results (see below).
CalibPPS/ESProducers
CondFormats/CTPPSReadoutObjects
CondFormats/DataRecord
DataFormats/CTPPSReco
Geometry/VeryForwardGeometryBuilder
RecoCTPPS/ProtonReconstruction
PR validation:
runTheMatrix.py -l limited --ibeos
resulted in30 29 28 22 16 4 1 1 1 tests passed, 4 0 0 0 0 0 0 0 0 failed
. The four failing tests (20034.0, 20434.0, 21234.0, 22034.0) reported:thus most likely unrelated to this PR.
Below a comparison of proton reconstruction performed with CMSSW_11_0_0_pre12 (blue) and this PR (red dashed) - there is no difference.