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
Run2-hcx192 Changes to DDHCalAngular by removing explicit reference to CLHEP #26271
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26271/8953
|
@cmsbuild Please test |
The tests are being triggered in jenkins. |
A new Pull Request was created by @bsunanda for master. It involves the following packages: Geometry/HcalAlgo @civanch, @Dr15Jones, @cvuosalo, @ianna, @mdhildreth, @cmsbuild can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
I still don't understand the source of the differences. You say the positioning is not changed by this PR. Then why are there differences? |
here is some python code that might be useful... def oldC(phi):
def newC(phi): for i in range(0,4000): |
} | ||
} | ||
|
||
double xpos = shiftX*cos(phi) - shiftY*sin(phi); | ||
double ypos = shiftX*sin(phi) + shiftY*cos(phi); | ||
double xpos = shiftX*cos(phix) - shiftY*sin(phix); |
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.
otherwise, this is only equivalent to the old implementation for integer values of convertRadToDeg(startAngle)
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 have made some tests with new vs old implementation and then test new==old. You see this test fail in many cases. Theta is 90 degree. pi and twopi match. All iphi's are the same but phideg or phi (phix) do not in many cases.
Theta 1.5708:1.5708:1
Pi 3.14159:3.14159:1 TwoPi 6.28319:6.28319:1
phideg 270:270:1 iphi 270:270 phi 4.71239:4.71239:1
phideg 300:300:1 iphi 300:300 phi 5.23599:5.23599:1
phideg 330:330:0 iphi 330:330 phi 5.75959:5.75959:0
phideg 0:0:1 iphi 0:0 phi 0:0:1
phideg 30:30:0 iphi 30:30 phi 0.523599:0.523599:1
phideg 60:60:0 iphi 60:60 phi 1.0472:1.0472:1
phideg 90:90:1 iphi 90:90 phi 1.5708:1.5708:1
phideg 120:120:0 iphi 120:120 phi 2.0944:2.0944:1
phideg 150:150:0 iphi 150:150 phi 2.61799:2.61799:0
phideg 180:180:0 iphi 180:180 phi 3.14159:3.14159:0
phideg 210:210:0 iphi 210:210 phi 3.66519:3.66519:0
phideg 240:240:0 iphi 240:240 phi 4.18879:4.18879:1
So my conclusion is that these are all rounding effects and once there is random # sequence goes crazy.
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.
@bsunanda: Could you please explain the print-out above with phideg, iphi, etc.? I don't see any differences.
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.
The first # is the new value, the second is the old value and the third is (old == new). I did not put (old==new) for int32 like iphi. But in many cases old==new fails and shows 0 which is due to some rounding issues. This is the culprit for change is random # sequence. This always causes difference for small samples but statistically they balance out
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.
Frankly I am now not worried about this difference
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.
It would be helpful to see (old - new) when they differ to understand the scale of the differences.
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.
The difference is at the level of e-14. Here they are. For each, there are the new value, old value, difference and test of new==old results
Theta 1.5708:1.5708:0:1
Pi 3.14159:3.14159:0:1 TwoPi 6.28319:6.28319:0:1
phideg 270:270:0:1 iphi 270:270:0:1 phi 4.71239:4.71239:0:1
phideg 300:300:0:1 iphi 300:300:0:1 phi 5.23599:5.23599:0:1
phideg 330:330:5.68434e-14:0 iphi 330:330:0:1 phi 5.75959:5.75959:8.88178e-16:0
phideg 0:0:0:1 iphi 0:0:0:1 phi 0:0:0:1
phideg 30:30:-3.55271e-15:0 iphi 30:30:0:1 phi 0.523599:0.523599:0:1
phideg 60:60:-7.10543e-15:0 iphi 60:60:0:1 phi 1.0472:1.0472:0:1
phideg 90:90:0:1 iphi 90:90:0:1 phi 1.5708:1.5708:0:1
phideg 120:120:-1.42109e-14:0 iphi 120:120:0:1 phi 2.0944:2.0944:0:1
phideg 150:150:-2.84217e-14:0 iphi 150:150:0:1 phi 2.61799:2.61799:-4.44089e-16:0
phideg 180:180:-2.84217e-14:0 iphi 180:180:0:1 phi 3.14159:3.14159:-4.44089e-16:0
phideg 210:210:-2.84217e-14:0 iphi 210:210:0:1 phi 3.66519:3.66519:-8.88178e-16:0
phideg 240:240:-2.84217e-14:0 iphi 240:240:0:1 phi 4.18879:4.18879:0:1
The tests are being triggered in jenkins. |
@cvuosalo - you can check if it has any impact on calo geometry by running the following validation: https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideDDDversusDataBaseValidation#Calo_Geometry |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 I am still perplexed about how the very tiny change in this PR related to rounding could cause thousands of differences. But if no one else sees a problem, I won't hamper progress. For the record, here is Sunanda's explanation: |
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 Could you please merge this PR. Like to use one of the methods in DDTypes to subsequent PR's which are in queue |
@fabiocos Could you please merge this PR? |
+1 differences affecting upgrade workflows, it would be better to cross check the explanation of @bsunanda with a higher statistics test |
@bsunanda the differences are seen only in upgrade workflows because they are producing geometry from DD on the fly, and not using snapshots from DB. Your explanation sounds plausible, but do you have a test independent on MC simulation dumping the geometry positions and showing that the differences are marginal? |
@fabiocos I printed the geometry positions and found out that they had identical values in print outs. |
@bsunanda ok, thanks, that is the check that I was interested in |
PR description:
Remove explicit reference to CLHEP from DDHCalAngular and also making changes to debug statements
PR validation:
Run the code with debug On which prints out the positioning with translation and rotation in this algorithm for all calls in the new and the older versions and make a diff which results no difference:
diff -bw /build/sunanda/CMSSW_10_6_X_2019-03-26-2300/relval/dump2.log dump.log
1c1
< Begin processing the 1st record. Run 1, Event 1, LumiSection 1 on stream 0 at 27-Mar-2019 18:59:23.481 CET
if this PR is a backport please specify the original PR:
Need to go to master and is the first step before translating this for dd4hep