-
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
ETL v5 (D73) x,y axes swapped and hardcoded offset removed #32472
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32472/20378
|
A new Pull Request was created by @martatornago (martatornago) for master. It involves the following packages: Geometry/MTDCommonData @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test since we do not have tests for scenario D73 in the short matrix I do not expect any visible effect here |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-81494c/11610/summary.html Comparison SummarySummary:
|
The reported DQM differences have nothing to do with this PR |
I suggest to put this PR on hold untile we have a private validation test of a full D73 workflow with it |
It's acceptable to have a PR that just adds the geometry without a complete scenario, if that's useful for development. However, this PR doesn't even add a geometry scenario, so its utility seems very limited. |
@kpedro88 as you can see this is just ETL for scenario D73, this PR is fixing a global 90-degree rotation that I realized in my checks on reco geometry and was confirmed by the updated full validation plots by @gsorrentino18 (see https://indico.cern.ch/event/984445/contributions/4146432/attachments/2161556/3647170/MTD-DPG%2011_12_2020.pdf slide 7, module rows should run along x and not y). While @martatornago has performed standalone checks comparing the dumped positions with the expected ones, I'd like to run a complete D73 test myself with it before merging. |
BTW it would make sense to backport this into 11_2_X, if we want to use that release for any meaningful test |
Ah sorry, I had forgotten D73 was already introduced. |
The Constants sections starts with this line:
I think the |
@martatornago was the output of the DDD and DD4hep versions of the geometry compared? are they identically equal? |
@fabiocos no, there is no reason to choose the other form. We forgot to choose "true" in that line. |
@fabiocos I’ve just checked again with both DDD and DD4hep and they are identical, yes.
… Il giorno 15 dic 2020, alle ore 10:01, Fabio Cossutti ***@***.***> ha scritto:
@martatornago <https://github.com/martatornago> was the output of the DDD and DD4hep versions of the geometry compared? are they identically equal?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#32472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO5I3LT2TN6CZ7EN44LYNGDSU4QYNANCNFSM4U2Y7CNA>.
--
------------------------
Indirizzo istituzionale di posta elettronica
degli studenti e dei laureati dell'Università degli Studi di TorinoOfficial
University of Turin email address for students and graduates
|
@martatornago thanks, I anyway suggest to fix the |
Pull request #32472 was updated. @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88 can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-81494c/11690/summary.html Comparison SummarySummary:
|
@fabiocos Units for lengths in the XML files can be added in a later PR. |
+1 |
@cvuosalo sorry, where do you see missing units? The constants are pure numbers, but then the units are added where constants are used, is this invalid? The DD4hep geometry output is identical to the DDD one according to the dumps. |
@fabiocos The following sound like lengths to me:
Isn't a thickness a length? I assume it would be measured in cm or mm.
This specification is for readability. If I want to find out the units for a constant, it would seem natural to go to the source XML. If the XML does not have the units, then I have to search around in the source code to try to figure out what the units are. |
@cvuosalo you are correct, but the units are specified in the instructions where these parameters are used. So strictly speaking I would say that the XML gives a correct result, unless units are missing somewhere. A different story might be using these constants somewhere else without specifying the unit. One may move units from the body to the constant definition, but this would require sometime, and I would factorize it from this fix |
+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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
@fabiocos Let's know when the tests are done. Thanks! |
I tested this PR with 200 TTbar events in the D73 scenario (WF 33434). |
thanks to the test of @gsorrentino18 I would say that a basic validation of this PR has been done, and I consider it enough to merge it. As discussed above, @martatornago will provide a further update addressing the technical comments by @cvuosalo and a possible further update of some design details. |
@fabiocos ok, thanks |
@silviodonato yes, actually I reduced the value from 310mm to 300mm because the inner radius of the geometry has changed (in fact with 310mm there were some overlaps) |
+1 |
PR description:
X and y axes, along which ETL modules and service hybrids are placed, have been swapped, and the phi angle of the disks has been properly adapted. In addition, hardcoded offsets previously introduced have been removed. These changes fix the errors present in the previous version, according to what has been presented by N. Koss at the last CMS week
PR validation:
Visualization of the geometry with Fireworks
Verified there are no overlaps with g4OverlapCheck_cfg.py
Check of the modules position by comparing x,y,z coordinates with the ones in the log produced by testMTDinDD4hep.py
if this PR is a backport please specify the original PR and why you need to backport that PR:
Before submitting your pull requests, make sure you followed this checklist: