-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
HGCalWaferValidation: refinements and D86 geometry validation fix #36502
HGCalWaferValidation: refinements and D86 geometry validation fix #36502
Conversation
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36502/27377
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36502/27378
|
A new Pull Request was created by @imranyusuff for master. It involves the following packages:
@emanueleusai, @ahmad3213, @cmsbuild, @jfernan2, @pmandrik, @pbo0, @rvenditti can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@imranyusuff can you please add yourself along with your github username in the comments filed to the HGCAL Validation developers e-group to keep track of the people working on it? |
Hi, I have just done that and is now waiting approval. |
if (geoThickClass == 0 && fileThickness == 120) | ||
return true; | ||
if (geoThickClass == 1 && fileThickness == 200) | ||
return true; |
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.
aren't these ifs else if ?
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.
Given the return
statements, else if
would act exactly the same
: waferShapeStr == "2" ? HGCalTypes::WaferPartialType::WaferChopTwoM | ||
: waferShapeStr == "3" ? HGCalTypes::WaferPartialType::WaferSemi2 | ||
: waferShapeStr == "4" ? HGCalTypes::WaferPartialType::WaferSemi2 | ||
: waferShapeStr == "5" ? HGCalTypes::WaferPartialType::WaferFive2 |
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.
Same comment applies here, both for the if
and for the map
.
Also, labelling evolution as new
and old
will tell us nothing the moment we have more than 2 versions. It would be better to either express is clearly with version numbers or use other labels.
: shapeStr == "am" ? HGCalTypes::WaferPartialType::WaferHalf2 | ||
: shapeStr == "b" ? HGCalTypes::WaferPartialType::WaferFive | ||
: shapeStr == "bm" ? HGCalTypes::WaferPartialType::WaferFive2 | ||
: shapeStr == "c" ? HGCalTypes::WaferPartialType::WaferThree |
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.
To be honest, it is the first time I see these long chains. Tabbed as such it is still quite readable, in my opinion (it wouldn't be with a different indentation, though). I've personally nothing against it,
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 prefer this way because:
- Makes things more readable, in table-like form
- Allows assignment to a
const
, which makes things more robust
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.
Surely the changed code is more readable
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 kind of agree with the comment from @jfernan2
From the performance point of view, there's no gain.
From the readability, the if
-else
is definitely more readable.
On a related note, instead of having this huge cascade of cases, would it make sense to have a map that, given the shapeStr
will return the correct WaferPartialType
? This would make the code even more readable.
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.
You mean define a constant std::map
within this module?
Then we would need 3 maps for that. One for old format mapping and DD, one for newer format low-density mapping and another one for newer format high-density mapping.
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.
Yes, a std::map
would do the job perfectly.
Keep in mind that the handling of the old format is just temporary and, as soon as we converge on something close to final, we can simply drop the rest.
Thanks!
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.
Thanks! Will implement this now.
please test |
assign hgcal-dpg |
New categories assigned: hgcal-dpg @felicepantaleo,@rovere,@pfs,@cseez you have been requested to review this Pull request/Issue and eventually sign? Thanks |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ab9735/21286/summary.html Comparison SummarySummary:
|
@rovere now I have implemented |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36502/27426
|
Pull request #36502 was updated. @pfs, @cseez, @felicepantaleo, @emanueleusai, @ahmad3213, @cmsbuild, @jfernan2, @rovere, @pmandrik, @pbo0, @rvenditti can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ab9735/21346/summary.html Comparison SummarySummary:
|
+1 |
waferInfo.shapeCode = HGCalTypes::WaferPartialType::WaferChopTwo; | ||
else if (shapeStr == "gm") | ||
waferInfo.shapeCode = HGCalTypes::WaferPartialType::WaferChopTwoM; | ||
waferInfo.shapeCode = waferShapeMapDD.at(shapeStr); |
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.
at
has bounds-checking
and, therefore, is slower. Since this is not reconstruction code, we can skip that for now and eventually use the direct []
access operator for later.
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.
Yes, I did try to use []
first but failed to compile because it cannot accept const std::map
.
@jfernan2 do you understand the |
They are ONLY in wf 11634.7 which is misbehaving in all the PRs active around at present: |
Thanks a lot for the info! |
+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. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Changelog Tue, 14 Dmr 2021 by Imran Yusuff:
PR validation:
Now correctly validates wafer with layerType = 3:
However, there still remain 6 rotation errors, all on layer number 33.
Testing with D77 and D83 geometries produced unchanged results.
No other bugs found during testing.
(- Imran -)