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

Use mayConsumes in VolumeBasedMagneticFieldESProducerFromDB #28120

Conversation

Dr15Jones
Copy link
Contributor

PR description:

The module decides which geometry to read from the database by reading the value stored in the MagFieldConfig EventSetup object. The decision cannot be made at module configuration time, only at run time. Therefore mayConsumes must be used.

Unit tests were added to guarantee the module's behavior is the same after this change.

PR validation:

  • Ran a slightly modified version of ​MagneticField/​Engine/​test/​testMagneticFieldDB.py where the comparison field map file was copied from afs and read locally. This test showed no changes.
  • Created a host of new unit tests which check the field value at (0,0,0) for all different configurations of VolumeBasedMagneticFieldESProducerFromDB. The comparison values were obtained from running the tests on the orginal version of the module. All the new unit tests pass.

This also included a test for RunInfoTestESProducer.
This is used to test VolumeBasedMagneticFieldESProducerFromDB.
The module decides which geometry to read from the database by
reading the value stored in the MagFieldConfig EventSetup object.
The decision cannot be made at module configuration time, only at
run time. Therefore mayConsumes must be used.

Unit tests were added to guarantee the module's behavior is the
same after this change.
@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28120/12156

  • This PR adds an extra 24KB to repository

@Dr15Jones
Copy link
Contributor Author

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

A new Pull Request was created by @Dr15Jones (Chris Jones) for master.

It involves the following packages:

CondFormats/MFObjects
CondTools/RunInfo
MagneticField/GeomBuilder

@perrotta, @slava77, @christopheralanwest, @tocheng, @cmsbuild, @franzoni, @tlampen, @ggovi, @pohsun can you please review it and eventually sign? Thanks.
@tocheng, @namapane, @mmusich, @seemasharmafnal 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

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/2818/console Started: 2019/10/07 16:36

@namapane
Copy link
Contributor

namapane commented Oct 7, 2019

I'm completely lost in the logic behind these modifications. Since we are also in the middle of migrating the same files to DD4hep, including some planned cleanup of eg. test .py, can you please wait before proceeding with this PR?

@Dr15Jones
Copy link
Contributor Author

Dr15Jones commented Oct 7, 2019

@namapane we are working towards requiring all ESProducers to call consumes. We are very close except for a few modules which need a functional mayConsumes (like the present implementation of VolumeBasedMagneticFieldESProducerFromDB).

If your upcoming changes can all work with calling consumes, then great. If the algorithm can not know what it needs to get from the EventSetup system at configuration time, we can work with you to setup the proper mayConsume calls.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

Comparison job queued.

@namapane
Copy link
Contributor

namapane commented Oct 7, 2019

@Dr15Jones, I do understand the idea behind mayConsumes; but I'm puzzled by the fact that moving to mayConsume requires so many changes in the code, and I am not sure I understand all their implications. The migration to DD4hep would be a clone of the producer with the same functional logic, so it will also require mayConsumes.
Also the "unit tests" do not make sense for me, at least at a first look, see comments to the code. If you insist in releasing these unit tests please move them to a separate folder. I would prefer these not to be released at all since (a) they make up for a very poor test of the actual configuration [I can provide details if needed]; (b) the new DD4hep producer will require complete tests anyhow; (c) we will probably have to declare some non-standard currents obsolete which will break some of these tests (which I don't want to have to maintain myself given (a) and (b))

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 7, 2019

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

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 34
  • DQMHistoTests: Total histograms compared: 2961052
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2960710
  • DQMHistoTests: Total skipped: 341
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
  • Checked 147 log files, 16 edm output root files, 34 DQM output files

@slava77
Copy link
Contributor

slava77 commented Oct 14, 2019

@namapane
please clarify if you are OK with this PR.
Thank you.

@namapane
Copy link
Contributor

Yes, everything fine for me. Thanks for checking.

@ggovi
Copy link
Contributor

ggovi commented Oct 15, 2019

+1

@slava77
Copy link
Contributor

slava77 commented Oct 16, 2019

+1

for #28120 9d98541

  • code changes are in line with the PR description and the follow up review. Changes in the reco category are only in MagneticField/GeomBuilder/plugins/VolumeBasedMagneticFieldESProducerFromDB.cc
  • jenkins tests pass and comparisons with the baseline show no (relevant) differences

@fabiocos
Copy link
Contributor

@christopheralanwest @pohsun could you please have a look at this PR?

@fabiocos
Copy link
Contributor

@christopheralanwest @pohsun any remark?

@fabiocos
Copy link
Contributor

@christopheralanwest @pohsun @tocheng @tlampen could you please check this PR? I would like to finally move it forward, and CondFormats/MFobjects is directly under AlCa supervision

@pohsun
Copy link

pohsun commented Oct 19, 2019

+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

code-checks

@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-28120/12344

  • This PR adds an extra 28KB to repository

  • Found files with invalid states:

    • MagneticField/GeomBuilder/test/testMagneticFieldDB_parameterized_cfg.results:
    • MagneticField/GeomBuilder/test/python/testMagneticFieldDB_valueOverride_cfg.py:
    • MagneticField/GeomBuilder/test/python/testMagneticFieldDB_parameterized_cfg.py:
    • MagneticField/GeomBuilder/test/testMagneticFieldDB_cfg.results:
    • MagneticField/GeomBuilder/test/python/testMagneticFieldDB_cfg.py:
    • MagneticField/GeomBuilder/test/testMagneticFieldDB.sh:
    • MagneticField/GeomBuilder/test/testMagneticFieldDB_valueOverride_cfg.results:

@fabiocos
Copy link
Contributor

+1

@cmsbuild cmsbuild merged commit bee8b7a into cms-sw:master Oct 20, 2019
@Dr15Jones Dr15Jones deleted the mayConsumeVolumeBasedMagneticFieldESProducerFromDB branch October 22, 2019 23:13
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

8 participants