acts-project
[WIP] feat: import of ePIC detector geometry into gen3
Not for merging.
This PR imports the ePIC detector geometry (current https://github.com/eic/epic main branch) into the Gen3 blueprints.
This is a draft PR simply intended to allow for sharing and commenting on code. Status in the comments since likely to change as new commits land.
This branch currently loads the geometry with a few exceptions:
- beampipe: hardcoded as in ODD, not imported from volume.
- VertexBarrel: QOL issue where we have a hardcoded constant number of z bins, but variable dd4hep constant for phi bins -> introduced a dd4hep constant for z bins as well
- ForwardTOF: no surfaces can be found for ForwardTOF_layer2 (but works fine for layer1)
LayerBlueprintNode: no surfaces provided for ForwardTOF_layer2 - B0Tracker: no volumes found for this off-axis detector
VolumeStack requires at least one volume
With the following code
Acts::GeometryContext trackingGeoCtx;
ActsExamples::ePICDetector::Config detectorConfig;
detectorConfig.logLevel = Acts::Logging::Level::VERBOSE;
detectorConfig.dd4hepLogLevel = Acts::Logging::Level::WARNING;
detectorConfig.xmlFileNames.push_back(compact);
detectorConfig.name = compact;
ActsExamples::ePICDetector epicDetector(detectorConfig, trackingGeoCtx);
this runs through the following:
15:33:20 DD4hepDetect DEBUG *** Initial volume configuration:
15:33:20 DD4hepDetect DEBUG z: [ -1000.000 <- 0.000 -> 1000.000 ], r: [ 0.000 <-> 20.000 ]
15:33:20 DD4hepDetect DEBUG z: [ -134.906 <- 0.045 -> 134.996 ], r: [ 33.020 <-> 130.221 ]
15:33:20 DD4hepDetect DEBUG z: [ -256.500 <- 0.000 -> 256.500 ], r: [ 258.016 <-> 274.793 ]
15:33:20 DD4hepDetect DEBUG z: [ -401.500 <- 0.000 -> 401.500 ], r: [ 413.039 <-> 429.572 ]
15:33:20 DD4hepDetect DEBUG z: [ 244.845 <- 249.865 -> 254.885 ], r: [ 31.763 <-> 245.000 ]
15:33:20 DD4hepDetect DEBUG z: [ -254.885 <- -249.865 -> -244.845 ], r: [ 31.763 <-> 245.000 ]
15:33:20 DD4hepDetect DEBUG z: [ 444.845 <- 449.865 -> 454.885 ], r: [ 31.763 <-> 420.000 ]
15:33:20 DD4hepDetect DEBUG z: [ -454.885 <- -449.865 -> -444.845 ], r: [ 31.763 <-> 420.000 ]
15:33:20 DD4hepDetect DEBUG z: [ 694.845 <- 1024.865 -> 1354.885 ], r: [ 33.460 <-> 426.400 ]
15:33:20 DD4hepDetect DEBUG z: [ -1024.885 <- -834.865 -> -644.845 ], r: [ 31.763 <-> 426.400 ]
15:33:20 DD4hepDetect DEBUG z: [ -980.000 <- 212.500 -> 1405.000 ], r: [ 546.755 <-> 588.755 ]
15:33:20 DD4hepDetect DEBUG z: [ -1675.000 <- 25.000 -> 1725.000 ], r: [ 730.965 <-> 762.162 ]
15:33:20 DD4hepDetect DEBUG z: [ 1498.995 <- 1567.995 -> 1636.995 ], r: [ 76.240 <-> 405.000 ]
15:33:20 DD4hepDetect DEBUG z: [ -1211.995 <- -1142.995 -> -1073.995 ], r: [ 65.000 <-> 405.000 ]
15:33:20 DD4hepDetect DEBUG z: [ -1110.000 <- 175.000 -> 1460.000 ], r: [ 629.336 <-> 654.424 ]
15:33:20 DD4hepDetect DEBUG z: [ 1856.187 <- 1861.337 -> 1866.487 ], r: [ 101.000 <-> 601.802 ]
15:33:20 DD4hepDetect VERBOSE Checking volume alignment
15:33:20 DD4hepDetect VERBOSE Checking volume #0 at z: 0
15:33:20 DD4hepDetect VERBOSE - Local transform is:
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
15:33:20 DD4hepDetect VERBOSE -> Rotation is ok!
15:33:20 DD4hepDetect VERBOSE -> Translation in x/y is ok!
15:33:20 DD4hepDetect VERBOSE Checking volume #1 at z: 0.045
15:33:20 DD4hepDetect VERBOSE - Local transform is:
1 0 0 0
0 1 0 -3.55271e-15
0 0 1 0.045
0 0 0 1
15:33:20 DD4hepDetect VERBOSE -> Rotation is ok!
15:33:20 DD4hepDetect VERBOSE -> Translation in x/y is ok!
15:33:20 DD4hepDetect VERBOSE Checking volume #2 at z: 0
15:33:20 DD4hepDetect VERBOSE - Local transform is:
1 0 0 0.0402683
0 1 0 0
0 0 1 0
0 0 0 1
15:33:20 DD4hepDetect VERBOSE -> Rotation is ok!
15:33:20 DD4hepDetect ERROR Volumes are not aligned: translation in x or y
terminate called after throwing an instance of 'std::invalid_argument'
what(): Volumes are not aligned: translation in x or y
The volumes are not aligned due to the an asymmetric placement of support braces in the SiSagittaBarrel, https://github.com/eic/epic/pull/933/files#r2583195150. That may not be intentional, or maybe it is. In any case, the asymmetric placement of supports should not block the geometry from being converted at this point. The symmetry requirement should be evaluated.
Output with https://github.com/acts-project/acts/pull/4864/commits/ee1b8dfddd94fe222e5c42da6e8b01d8f208f1d4: test_ACTS_gen3.txt