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
Adding angle utilities #26227
Adding angle utilities #26227
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26227/8851
|
A new Pull Request was created by @cvuosalo (Carl Vuosalo) for master. It involves the following packages: DataFormats/Math @cmsbuild, @perrotta, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@VinInn, @fwyzard: If you have time and would like to comment, we would appreciate your thoughts on the following questions. For angle values that need to be kept in the range [0, 2pi), what coding approach best balances reliability, developer convenience, and performance? Does this PR achieve this balance, or could it be improved? |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Sorry, there are already N version of it. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
As before, the comparison test differences are almost entirely in two Phase 2 simulation workflows which have different random sequences in the SIM step. These differences are not due to this PR. I think all issues in this PR have been addressed, so I hope it can be soon approved. |
+1 |
+1
|
+1 |
+upgrade |
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) |
+1 |
// calling fmod to improve performance. | ||
|
||
template <class valType> | ||
inline constexpr valType make0To2pi(valType angle) { |
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.
commenting here instead of in #27637
about angle0to2pi
IMHO, it would be more consistent to move it up in this file to the reco namespace and rename to reduceRange0To2pi
Also, if it's implementation is really faster, replace the current reduceRange
of [-pi,pi] with the faster variant.
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.
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.
Concerning the possible replacement of reduceRange
: Since make0To2pi
checks for floating-point value drift over repeated calculations and reduceRange
does not, there is a good possibility that comparison tests for replacing reduceRange
would show small differences. make0To2pi
should provide more correct results, but it would be required to show that the comparison test differences were correct, appropriate, and desirable, which might be a challenge. I did not replace reduceRange
in this PR for this very reason.
Perhaps replacement could be done on a step-by-step basis by developers familiar with the applications getting changed so that the comparison differences would be easier to understand.
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.
I'd suggest putting everything in the file in the delta_phi
namespace to match the header file name, but I don't have a strong opinion about namespace naming.
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.
About the small differences, it should be acceptable, considering the expected speedup and improved numerical precision (unless perhaps a PR comes after the deadline with an "urgent" tag and some unrelated changes inside).
PR description:
In many spots in CMSSW, code like the following appears:
The intent is to constrain the angle to the range 0<= angle < 2pi, but the code, as in this example, sometimes doesn't handle the case of an |angle| >= 4pi.
DataFormats/Math/interface/deltaPhi.h
provides areduceRange()
function for this purpose, but tests show this function is not as fast as it could be, and it suffers from sensitivity in itsif
statement to small deviations from pi.This PR adds a new function
make0to2pi
, that can be significantly faster thanreduceRange()
and that greatly reduces value drift due to floating-point comparisons. This new function is added without changing the implementation ofreduceRange()
because changingreduceRange()
could cause slight differences in program behavior. Usage ofreduceRange()
can later be replaced on a case-by-case basis where better performance and precision is required.The
Phi
class inDataFormats/GeometryVector/interface/Phi.h
represents an angle that maintains a value from -pi to pi. This PR enhances this class in a backwardly compatible fashion to allow the option of keeping the angle in the range from 0 to 2pi.In addition, the generic angle utilities in the
GeantUnits.h
file are moved todeltaPhi.h
because they are not Geant-specific and should be usable without subjecting code to Geant conventions.PR validation:
A unit test program is included in this PR, and it verifies basic functions of the code and gives some rough performance measures.
Some performance results comparing
reduceRange()
andmake0to2pi
are shown below.The entry for the
Phi
templates in theclasses_def.xml
file uses ClassVersion 3 because the revised template is effectively a new class. No problems with the ROOT dictionary forPhi
were observed. Using baseline CMSSW_10_6_0_pre2 code without this PR, I wrote aPhi
variable to a ROOT file. Then, with the new PR code, I could successfully read thePhi
variable out of that same ROOT file, so there appears to be backwards compatibility in reading old ROOT files containing thePhi
class. However, a scan of CMSSW finds no cases wherePhi
variables were written to ROOT files, so it doesn't look like the ability to read the old version ofPhi
variables in ROOT files is even needed.No backport is needed.