Various issues implemented (Issue #371, #373, #378)

[MarkusFrankATcernch]

BEGINRELEASENOTES

Implementation of non-cylindrical tracking region (resolves #371)

• It is possible to define volumes in a parallel world such as e.g. a tracking region. In principle any volume hierarchy may be attached to the parallel world. None of these volumes participate in the tracking as long as the "connected" attribute is set to false. The hierarchy of parallel world volumes can be accessed from the main detector object using

  dd4hep::Volume parallel = dd4hep::Description::parallelWorldVolume()

This parallel world volume is created when the geometry is opened together (and with the same dimensions) as the world volume itself.

• IF the NAME of the volumes is "tracking_volume" within the compact notation it is declared as the Detector's trackingVolume entity and is accessible as well:

  dd4hep::Volume trackers = dd4hep::Description::trackingVolume()

• Although the concept is available in the DD4hep core, it's configuration from XML is only implemented for the compact notation. For details see the example examples/ClientTests/compact/TrackingRegion.xml.
• If the volume should be connected to the world: connected="true". This is useful for debugging because the volume can be visualized else if the volume is part of the parallelworld: connected="false". The volume is always connected to the top level. The anchor detector element defines the base transformation to place the volume within the (parallel) world.

     <parallelworld_volume name="tracking_volume" anchor="/world" material="Air" connected="true" vis="VisibleBlue">
       <shape type="BooleanShape" operation="Subtraction">
         <shape type="BooleanShape" operation="Subtraction">
           <shape type="BooleanShape" operation="Subtraction"  >
             <shape type="Tube" rmin="0*cm" rmax="100*cm" dz="100*cm"/>
             <shape type="Cone" rmin2="0*cm" rmax2="60*cm" rmin1="0*cm" rmax1="30*cm" z="40*cm"/>
             <position x="0*cm" y="0*cm" z="65*cm"/>
           </shape>
           <shape type="Cone" rmin1="0*cm" rmax1="60*cm" rmin2="0*cm" rmax2="30*cm" z="40*cm"/>
           <position x="0" y="0" z="-65*cm"/>
         </shape>
         <shape type="Cone" rmin2="0*cm" rmax2="55*cm" rmin1="0*cm" rmax1="55*cm" z="30*cm"/>
         <position x="0" y="0" z="0*cm"/>
       </shape>
       <position x="0*cm"   y="50*cm" z="0*cm"/>
       <rotation x="pi/2.0" y="0"     z="0"/>
     </parallelworld_volume>

Enhancement of assemblies, regions and production cuts (resolves #373)

On request from FCC particle specific production cuts may be specified in the compact notation. These production cuts (Geant4 currently supports these for e+, e-, gammas and protons) are specified as "cut" entities in the limitset. (See the example examples/ClientTests/compact/Assemblies.xml).

• The hierarchy of cuts being applied is:
  • If present particle specific production cuts for a region are applied.
  • else the "cut" attribute of the compact region specification is used
  • else the global Geant4 cut is automaticallly applied by Geant4.

  <limits>
    <limitset name="VXD_RegionLimitSet">
      <!--
           These are particle specific limits applied to the region
           ending in Geant4 in a G4UserLimits instance
      -->
      <limit name="step_length_max"  particles="*" value="5.0" unit="mm" />
      <limit name="track_length_max" particles="*" value="5.0" unit="mm" />
      <limit name="time_max"         particles="*" value="5.0" unit="ns" />
      <limit name="ekin_min"         particles="*" value="0.01" unit="MeV" />
      <limit name="range_min"        particles="*" value="5.0" unit="mm" />

      <!--
           These are particle specific production cuts applied to the region
           ending in Geant4 in a G4ProductionCuts instance
      -->
      <cut   particles="e+"          value="2.0"   unit="mm" />
      <cut   particles="e-"          value="2.0"   unit="mm" />
      <cut   particles="gamma"       value="5.0"   unit="mm" />
    </limitset>
  </limits>

SensitiveDetector types not changed by Geant4SensDetActionSequence (resolves #378)

The sensitive detector type defined in the detector constructors is no longer changed intransparently in the back of the users. This may have side-effects for creative detector constructor writers, who invent sd types out of the sky. These obviously will not work with Geant4, because in Geant4 a mapping of these types must be applied to supported sensitive detectors. Now the mapping of a sd type (e.g. "tracker") is strict in the python setup. The default factory to create any sensitive detector instance in Geant4 (ie. an object of type G4VSensitiveDetector, G4VSDFilter, Geant4ActionSD) is a property of the Geant4Kernel instance and defaults to:

 declareProperty("DefaultSensitiveType", m_dfltSensitiveDetectorType = "Geant4SensDet");

• Since the actual behavior is defined in the sequencer instanciated therein this default should be sufficient for 99.99 % of all cases. Otherwise the factory named "Geant4SensDet" may be overloaded.

ENDRELEASENOTES