Introduce vFloat and float types in ParameterSets

[felicepantaleo]

Description

This pull request introduces vFloat and float types in the ParameterSets of the CMSSW framework. The changes aim to improve the precision and performance of floating-point parameter handling in configuration sets.

Changes

1. Added vFloat and float type definitions.
2. Updated relevant configuration files to utilize the new types.
3. Ensured compatibility with existing functionality and modules.

This will allow the developers of C++ modules to directly use std::vector<float> configuration parameters avoiding manually converting each of them from std::vector<double>, if double precision is not needed.

Testing

• Ran all existing unit tests.
• Added new tests to cover the vFloat and float types.
• Tested with workflow 24900.0.
• Verified no regressions in performance or functionality.

Future Work

If the tests run smoothly, an existing reconstruction module will be migrated from double to float within this pull request.

@smuzaffar @makortel @Dr15Jones @fwyzard @rovere @VinInn FYI

[cmsbuild]

cms-bot internal usage

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45216/40573

• This PR adds an extra 132KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File FWCore/ParameterSet/python/Config.py modified in PR(s): faster edmConfigDump with --prune, also prunes unreferenced PSets #43276

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

• code-format:
  https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45216/40573/code-format.patch
  e.g. curl -k https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45216/40573/code-format.patch | patch -p1
  You can also run scram build code-format to apply code format directly

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45216/40574

• This PR adds an extra 124KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File FWCore/ParameterSet/python/Config.py modified in PR(s): faster edmConfigDump with --prune, also prunes unreferenced PSets #43276

[cmsbuild]

A new Pull Request was created by @felicepantaleo for master.

It involves the following packages:

• FWCore/ParameterSet (core)
• FWCore/PythonParameterSet (core)

@cmsbuild, @makortel, @Dr15Jones, @smuzaffar can you please review it and eventually sign? Thanks.
@makortel, @missirol, @wddgit this is something you requested to watch as well.
@sextonkennedy, @rappoccio, @antoniovilela you are the release manager for this.

cms-bot commands are listed here

[felicepantaleo]

test parameters:

• workflow = 25288.203,25488.203

[felicepantaleo]

@cmsbuild please test

[cmsbuild]

-1

Failed Tests: RelVals
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9ee9da/39871/summary.html
COMMIT: 4e3d218
CMSSW: CMSSW_14_1_X_2024-06-13-1100/el8_amd64_gcc12
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/45216/39871/install.sh to create a dev area with all the needed externals and cmssw changes.

RelVals

ValueError: Undefined workflows: 25288.203, 25488.203

[felicepantaleo]

test parameters:

[felicepantaleo]

@cmsbuild please test

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45216/41805

• There are other open Pull requests which might conflict with changes you have proposed:
  • File FWCore/ParameterSet/python/Config.py modified in PR(s): faster edmConfigDump with --prune, also prunes unreferenced PSets #43276

[cmsbuild]

Pull request #45216 was updated. @Dr15Jones, @cmsbuild, @jfernan2, @makortel, @mandrenguyen, @smuzaffar can you please check and sign again.

[felicepantaleo]

@cmsbuild please test

[cmsbuild]

+1

Size: This PR adds an extra 28KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9ee9da/41534/summary.html
COMMIT: c97cd29
CMSSW: CMSSW_14_2_X_2024-09-15-2300/el8_amd64_gcc12
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/45216/41534/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially removed 3 lines from the logs
• Reco comparison results: 5 differences found in the comparisons
• DQMHistoTests: Total files compared: 44
• DQMHistoTests: Total histograms compared: 3331158
• DQMHistoTests: Total failures: 6
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3331132
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 43 files compared)
• Checked 193 log files, 163 edm output root files, 44 DQM output files
• TriggerResults: no differences found

[jfernan2]

+1

[makortel]

This will allow the developers of C++ modules to directly use std::vector<float> configuration parameters avoiding manually converting each of them from std::vector<double>, if double precision is not needed.

There are simpler ways to achieve an easier conversion from std::vector<double> to std::vector<float>, or enabling getParameter<std::vector<float>>(...), that would not require changes in the python configuration side. Could you describe what aspects, in addition to what you wrote in the PR description, you see as important so that it floating point precision is useful to be specified in the python configuration side as well?

(based on a cursory internal discussion we are leaning towards a separate configuration data type to be a better way, e.g. for consistency with the integer types and requiring consistency between fillDescriptions() and getParameter(), so this question is only about us learning what additional motivations do you have in mind)

[felicepantaleo]

ciao Matti, thanks for looking into this.
Apart from avoiding the ugly filling of the std::vector<float> from doubles in each producer, I think that specifying the floating point precision in the Python configuration offers type consistency across interfaces allows developers to control the numerical precision of parameters explicitly and help them not to focus on the implicit conversions in the code. With this PR I make any precision reduction intentional and visible, making the code more maintainable and easier to understand.

[felicepantaleo]

@makortel let me know if you have more comments

[makortel]

@felicepantaleo I'll have some comments, but have been distracted by other stuff (and will be for some days).

[cmsbuild]

Milestone for this pull request has been moved to CMSSW_15_0_X. Please open a backport if it should also go in to CMSSW_14_2_X.