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
Use mayConsumes in VolumeBasedMagneticFieldESProducerFromDB #28120
Conversation
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.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28120/12156
|
please test |
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages: CondFormats/MFObjects @perrotta, @slava77, @christopheralanwest, @tocheng, @cmsbuild, @franzoni, @tlampen, @ggovi, @pohsun can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
The tests are being triggered in jenkins. |
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? |
@namapane we are working towards requiring all ESProducers to call If your upcoming changes can all work with calling |
Comparison job queued. |
@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. |
Comparison is ready Comparison Summary:
|
@namapane |
Yes, everything fine for me. Thanks for checking. |
+1 |
@christopheralanwest @pohsun could you please have a look at this PR? |
@christopheralanwest @pohsun any remark? |
@christopheralanwest @pohsun @tocheng @tlampen could you please check this PR? I would like to finally move it forward, and |
+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) |
code-checks |
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28120/12344
|
+1 |
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:
(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.