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

PPS: update of Validation/CTPPS #28492

Merged
merged 4 commits into from
Dec 11, 2019

Conversation

jan-kaspar
Copy link
Contributor

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

  • new auxiliary modules added
  • for several modules: configurable input/output label

CondFormats/CTPPSReadoutObjects

  • a friend declaration added

CondFormats/DataRecord

  • CTPPSBeamParametersRcd made dependent on LHCInfoRcd (allows to change parameters with xangle)

DataFormats/CTPPSReco

  • few more dictionaries generated

Geometry/VeryForwardGeometryBuilder

  • store sensor type (to distinguish between pixel 2x2 and 3x2 modules)

RecoCTPPS/ProtonReconstruction

  • configurable input-optics label
  • timing-RP local track also stored in the reco proton contributor list

PR validation:

runTheMatrix.py -l limited --ibeos resulted in 30 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:

Exception: 'Phase2C4_timing_layer_bar' is not a valid option for '--era

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.
make_cmp

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28492/12937

  • This PR adds an extra 76KB to repository

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

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28492/12943

  • This PR adds an extra 76KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @jan-kaspar for master.

It involves the following packages:

CalibPPS/ESProducers
CondFormats/CTPPSReadoutObjects
CondFormats/DataRecord
DataFormats/CTPPSReco
Geometry/VeryForwardGeometryBuilder
RecoCTPPS/ProtonReconstruction
Validation/CTPPS

@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.
@forthommel, @rovere, @mmusich, @seemasharmafnal, @tocheng 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

@jfernan2
Copy link
Contributor

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 28, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/3677/console Started: 2019/11/28 09:31

@pohsun
Copy link

pohsun commented Dec 3, 2019

+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;
}
}
Copy link
Contributor

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.

Copy link
Contributor Author

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 .

Copy link
Contributor

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.

Copy link
Contributor

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.

@cvuosalo
Copy link
Contributor

cvuosalo commented Dec 4, 2019

+1

@jan-kaspar
Copy link
Contributor Author

@ggovi May I please ask for review? Db is the last signature missing and the changes in CondFormats are small and technical:

  • LHCInterpolatedOpticalFunctionsSet.h: only a friend declaration added
  • CTPPSBeamParametersRcd.h: made dependent on LHCInfoRcd (to allow updates upon crossing-angle changes)

Thanks in advance!

@ggovi
Copy link
Contributor

ggovi commented Dec 5, 2019

+1

@cmsbuild
Copy link
Contributor

cmsbuild commented Dec 5, 2019

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)

@jan-kaspar
Copy link
Contributor Author

Thanks @ggovi !

Copy link
Contributor

@fabiocos fabiocos left a 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
Copy link
Contributor

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...

Copy link
Contributor Author

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?

@jan-kaspar
Copy link
Contributor Author

@jan-kaspar why are alignment configuration files store inside Validation/CTPPS instead of some alignment package?

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?

@fabiocos
Copy link
Contributor

@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.

@jan-kaspar
Copy link
Contributor Author

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.

@fabiocos
Copy link
Contributor

+1

@cmsbuild cmsbuild merged commit c26f4e8 into cms-sw:master Dec 11, 2019
jan-kaspar added a commit to CTPPS/cmssw that referenced this pull request Jan 8, 2020
cmsbuild added a commit that referenced this pull request Jan 21, 2020
@jan-kaspar jan-kaspar deleted the pps_validation_update_11_0_0 branch January 24, 2020 17:26
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.

10 participants