Skip to content
Snippets Groups Projects

Helper Cone shapes in LArWheelSolid

Merged Andrei Sukharev requested to merge asoukhar/athena:cones-in-larwheelsolid into master
All threads resolved!

A new option to replace internal helper G4Polycone objects in LArWheelSolid with simpler (and thus faster) cone objects is introduced. (This address ATLASSIM-3778.)

For this purpose a local G4ShiftedCone class based on standard G4Cons is implemented. "Shifted" cone is necessary to keep G4Polycone-induced coordinate system.

LArWheelSliceSolid, representing a thin z-slice of LArWheelSolid and an option for its usage activation are also implemented. Such a setup could help Geant4 to make voxelization and also could have positive effect for issues like ATLASSIM-3314, ATLASSIM-3654, and maybe others (stuck tracks).

The geometry variant is controlled with

from LArGeoAlgsNV.LArGeoAlgsNVConf import LArDetectorToolNV
LArDetectorToolNV.EMECVariantInner=INNER_VARIANT
LArDetectorToolNV.EMECVariantOuter=OUTER_VARIANT

where INNER and OUTER_VARIANT could be "Cone" for LArWheelSolid+Cone helper shapes, "Slices" for LArWheelSliceSolid, or anything else for the old variant (LArWheelSolid with polycones). The default is "Wheel".

Both new variants give expected geantino tracking printout. For real particles, however, output ROOT files do have differences comparing to the old version, which is, to my understanding, also expected, since the geometry layout is changed in both variants. If the changes are acceptable should be decided with physical validation.

Edited by Andrei Sukharev

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Pavol Strizenec
  • Pavol Strizenec
  • Pavol Strizenec
    • Resolved by Peter Berta

      Hi Andrey,

      one more general comment, your class G4ShiftedCone is "clone" of G4 class and therefore doesn't follow the Atlas coding rules (for instance in naming conventions and maybe other points). Pinging @sroe and @ssnyder if they have any opinion on such case.

        Pavol [as L2 MR shifter]
  • Just to add here that in general for classes inheriting from G4 classes we tend to follow the Geant4 style.

  • added 1 commit

    • 1d2a322e - Changes to follow ATLAS coding rules.

    Compare with previous version

  • This merge request affects 5 packages:

    • DetectorDescription/GeoModel/GeoSpecialShapes
    • LArCalorimeter/LArG4/LArG4SD
    • LArCalorimeter/LArGeoModel/LArGeoAlgsNV
    • LArCalorimeter/LArGeoModel/LArGeoEndcap
    • Simulation/G4Utilities/Geo2G4

    Adding @jchapman ,@pavol ,@vpascuzz ,@rbianchi as watchers

  • :white_check_mark: CI Result SUCCESS

    Athena AthSimulation
    externals :white_check_mark: :white_check_mark:
    cmake :white_check_mark: :white_check_mark:
    make :white_check_mark: :white_check_mark:
    required tests :white_check_mark: :white_check_mark:
    optional tests :white_check_mark: :white_check_mark:

    Full details available at NICOS MR-25199-2019-08-05-15-59
    :white_check_mark: Athena: number of compilation errors 0, warnings 0
    :white_check_mark: AthSimulation: number of compilation errors 0, warnings 0
    :pencil: For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 1789]

  • Peter Berta resolved all discussions

    resolved all discussions

  • The code was already reviewed at L2 and the comments were implement by the developer. The latest CI is successful, therefore adding review-approved label.

    L1 shifter

  • added review-approved label and removed review-pending-level-1 label

  • mentioned in commit 58446c96

  • John Derek Chapman mentioned in merge request !25400 (closed)

    mentioned in merge request !25400 (closed)

  • We thinks this MR causes ATLASSIM-4271

  • Here are the benchmark results: EMEC_benchmark.pdf

  • Please register or sign in to reply
    Loading