jwebb's blog

Abstract: I have developed a prototype geometry differential framework. The purpose of this framework is (1) to track the evolution of the STAR geometry model as detectors are added, removed and/or modified, and (2) to provide information relevant to debugging physics issues in geometry models. A third purpose, (3) to provide a material budget in front of a given detector, will be developed for the final version.

1.0 Description of the Framework

2.0 Some Example Plots in the EEMC

3.0 Material Balance and Difference Histograms in the EEMC

1.0 Description of the Framework

The prototype framework is based on a Virtual Monte Carlo (VMC) application, written by Victor, Yuri, (others...?). The original code is available in CVS (under .dev) as StarVMC/GeoTestMaker. At present, the framework exists as a (not very user friendly) macro and compiled code. The next version will move some key components (binning of histograms, event generation, etc...) out of compiled code into the macro.

Tracking Global Changes to the STAR Geometry Model

A detector element in the STAR geometry model is represented by a volume. Each volume has an associated shape, a material and a tracking medium assigned to it. In short, four quantities are represented: (a) dimension, (b) position, (c) composition and (d) physical processes. Ideally we would like to track changes in these quantities.

Position -- A 2d histogram showing the r,z at the point where a geantino intersects each detector volume is filled with weight equal to the distance from the origin to that point of intersection.
Dimension -- A 2d histogram showing the r,z at the point where a geantino intersects each detector volume is filled with weight equal to the path length the geantino follows in passing through that volume.
Composition -- A 2d histogram showing the r,z at the point where a geantino intersects each detector volume is filled with weight equal to the radiation length (in g/cm2) reported by the model.
Physics -- This remains to be done.

A difference plot can then be made between any two instances of the STAR geometry, say, between y2009 and y2009a. Any differences observed can then be studied in more detail using the more expert-level part of the framework.

Debugging Subsystem Geometries

Tools already exist to visualize the shape and placement of detectors. The problem is that they will happily draw the detector volumes as defined... but the material associated with those volumes could be crazy (e.g. iron = air). The main purpose of this framework in debugging geometries is to fill in the additional information of "what material is seen by a particle traversing this volume". This is achieved by plotting the number of radiation lengths encountered as a function of the pseudorapidity of a geantino passing through the volume.

The volumes for which histograms are booked and filled are defined by the user in the macro. The definition would look something like:

    steps->bookVolume("ECAL"); // Endcap calorimeter envelope                                                                   
    steps->bookVolume("EMSS"); // Structural steel                                                                              
    steps->bookVolume("EFLP"); // Front plate                                                                                   
    steps->bookVolume("ECVO"); // Volumes w/ radiators and megatiles                                                            
      steps->bookVolume("EMOD"); // Endcap module (sector)                                                                      
    steps->bookVolume("ECV1"); // 2nd instance of ECVO, after the SMD layer
    steps->bookVolume("ESSP"); // Back plate                                                                                    
    steps->bookVolume("ERCM"); // Tie rods

steps->bookVolume("ESHM"); // Shower-maximum section steps->bookVolume("EPSB"); // Projective stainless steel bar steps->bookVolume("ECHC"); // CCStainless steel cover

The resulting histograms can be combined to show what the total radiation length for a given detector is, and what the contributions of each subdetector is. (n.b. that building such plots at this point requires a certain level of expertise with the geometry file, the vagaries associated with the AgSTAR automagic naming conventions, etc...)

2.0 Some Example Plots in the EEMC

Geantinos are thrown over a 30° range in phi, focused on more forward rapidities. The radiation length reported by the volume is plotted at the (r,z) coordinate at which the geantino first intersects the volume.

Figure 2.1 -- Y2009 geometry tag.

Figure 2.2 -- Y2009a geometry tag.

Figure 2.3 -- Difference between Y2009 and Y2009a geometries. The z-axis is shown in a modified grayscale, proportional to the absolute value of the difference in radiation lengths. Zero on the z-axis is anything less than 0.0001 times the maximum value of the axis, and is shown in a pale yellow to provide contrast (perhaps not enough contrast?). The speckles around z=300cm is not dirt on your laptop monitor... they are differences between the y2009 and y2009a geometries in the EEMC (the only detector which is supposed to have changed between the two geometries).

3.0 Material Balance / Debugging Histograms

We see changes in the radiation length based on the above plots, so it would be nice to be able to pin down which subvolumes of the endcap are responsible for the change. To that end, the framework allows the user to specify volumes to generate material budget plots for specified volumes.

Figure 3.1 -- Material balance for the EEMC. The EMSS is the steel structure of the endcap, and is the first physical volume of the EEMC. The ECVO and ECV1 volumes are the stainless steel clad lead radiators plus scintillator planes. The EFLP and ESSP are the front and backplates respectively. ESHM is the shower maximum volume.

Figure 3.2 -- Material balance difference between y2009 and y2009a for the full endcap, and various volumes within the endcap. The figures below show that the y2009a geometry has slightly less material than the y2009 geometry. This is likely due to the use of PbAlloy and Steel instead of pure lead and iron, as seen by examining the material shifts shown in panels (b-c) and (d).

(a) Difference between y2009 and y2009a for all EEMC volumes.