KKMaterial migration#1833
Conversation
|
Hi @brownd1978,
which require these tests: build. @Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main. ⌛ The following tests have been triggered for 94b1baf: build (Build queue - API unavailable) |
|
☔ The build tests failed for 94b1baf.
N.B. These results were obtained from a build of this Pull Request at 94b1baf after being merged into the base branch at 23fc715. For more information, please check the job page here. |
|
@FNALbuild run build test with Mu2e/mu2e-trig-config#162 |
|
⌛ The following tests have been triggered for 94b1baf: build (Build queue - API unavailable) |
|
☔ The build tests failed for 94b1baf.
N.B. These results were obtained from a build of this Pull Request at 94b1baf after being merged into the base branch at 23fc715. For more information, please check the job page here. |
|
Thanks Michael! |
|
@FNALbuild run build test with Mu2e/mu2e-trig-config#162, Mu2e/Production#541 |
|
⌛ The following tests have been triggered for 94b1baf: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 94b1baf.
N.B. These results were obtained from a build of this Pull Request at 94b1baf after being merged into the base branch at 23fc715. For more information, please check the job page here. |
| inputFile : "Offline/Mu2eG4/geom/geom_common.txt" | ||
| bFieldFile : "Offline/Mu2eG4/geom/bfgeom_v01.txt" | ||
| simulatedDetector : { tool_type: "Mu2e" } | ||
| KinKalMaterial : { |
There was a problem hiding this comment.
this seems like a good place to use @table from a KK prolog since the content is all static and relevant only to KK, it should be located in a KK directory
There was a problem hiding this comment.
I debated this mentally as well. These parameters are only used in KinKal but they describe the general detector.
Currently we describe the entire detector geometry for simulation and reconstruction with Mu2eG4/geom. This breaks the design intent that GeometryService be agnostic, since we can't run reconstruction without Mu2eG4 (and its Geant4 dependency) in the release/path. A truely agnostic solution is to put base geometry and material definitions in a neutral package. That would be a natural place then to put this KinKal material config.
For now I'll follow this suggestion, and create an issue for the bigger issue.
|
|
||
| namespace mu2e { | ||
| class KKMaterial { | ||
| class KKMaterial : public MatEnv::FileFinderInterface, public Detector, public ProditionsEntity { |
There was a problem hiding this comment.
I don't think this needs to be a proditionsentity unless it will have run dependence within one geometry file config, like alignment.
There was a problem hiding this comment.
I was following an existing pattern (Tracker) without thinking. Since we've firmly committed to not allowing multiple base geometries in 1 job I'll remove ProditionsEntity here and in KKGeom.
|
@FNALbuild run build test with Mu2e/mu2e-trig-config#162, Mu2e/Production#541 |
|
⌛ The following tests have been triggered for 9edc8a0: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 9edc8a0.
N.B. These results were obtained from a build of this Pull Request at 9edc8a0 after being merged into the base branch at 23fc715. For more information, please check the job page here. |
|
@rlcee I believe I addressed your issues, can you approve or provide further feedback? |
This PR moves KKMaterial from Mu2eKinKal to GeometryService. Previously, each client created its own instance of KKMaterial, which required duplicate configuration. Now there's one instance, with a single configuration in standard_services. This PR makes no functional change.
There are knockon changes required in Production, EventNtuple and mu2e-trig-config due to configuration and link dependency changes.
This PR is a precursor to creating material objects for KinKal extrapolation.