feat: import full HRPPD GDML as mRICH photo-detector #382
Conversation
github-actions
bot
added
topic: backward
|
Looks like this (only one box shown with children): |
|
@c-dilks Asked you to review this. Maybe there are useful approaches here for the dRICH? I think you should be able to get volumes by name out of the gdml, and then assign them sensor/module/segmentation. It is possibly a good 'CAD-light' approach. |
|
Perhaps. In a different context (and in a simple model case, where one can actually code them in OpenCascade directly) I'm using a different approach: have a CAD model and a gerber set for the matching PCB production done in the same ROOT script, in which case both models are automatically synchronized in terms of shapes, sizes, hole locations and such, as long as one does not make a coding mistake. It is obvious one can do the same for a CAD+GEANT output rather than a CAD+PCB combo. Essentially one is generating a GDML file and a CAD model of identical complexity at the same time. But then one can argue, why not use ROOT->CAD export, which is readily available. Anyway, my 2 cents. |
|
Whatever we do, it should be sustainable and reproducible; it would be good to document where these Speaking of documentation, should these |
|
Looks great, however there are some mRICH-mRICH overlaps, e.g.: https://github.com/eic/epic/actions/runs/4349674426/jobs/7599660505 |
|
not sure what we are supposed to see here. looks like mRICH embedded into pfRICH vessel?
…________________________________
From: Wouter Deconinck ***@***.***>
Sent: Monday, March 6, 2023 8:28 PM
To: eic/epic ***@***.***>
Cc: Kiselev, Alexander ***@***.***>; Mention ***@***.***>
Subject: Re: [eic/epic] feat: import full HRPPD GDML as mRICH photo-detector (PR #382)
Looks like this (only one box shown with children):
[image]<https://urldefense.com/v3/__https://user-images.githubusercontent.com/4656391/223295531-0331b932-33db-437b-9cc6-d44f86b16176.png__;!!P4SdNyxKAPE!DjteiVRVTAgqeeG9ekEzICiXg13YzanDPaZliuyfMch92flQccjs_5zvFD2XODO7xFJE9oRnPD-kHwBbISomsw$>
—
Reply to this email directly, view it on GitHub<#382 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANV7FILVTYPWDOHE3ZGF7D3W22FMNANCNFSM6AAAAAAVRXQDJA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
This branch (obviously) needs work since we changed the default to pfrich. There is no real value in having the mrich implemented in more detail, but there is value in having a proof of concept of having an imported gdml component to point to as an example. |
|
There are now several better examples of importing gdml in production code, so I'm going to close this. |
Briefly, what does this PR introduce?
Instead of implementing a detailed HRPPD model in xml with support in the geometry plugin, this just pulls in the GDML model from @alexander-kiselev.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
No.
Does this PR change default behavior?
No.